We will be discussing Chapter 6: The Lifecycle of a Domain Object.

This chapter dives into how domain objects live — from their creation through state changes to eventual retirement. I found several parts particularly insightful.

“An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.”

I love how this encapsulates not just grouping, but transactional consistency too. It’s not about objects sitting together, it’s about managing invariants collectively.

I appreciated the car-and-tire example: it shows that the car, as the aggregate root, governs whether tires belong to it, preventing loose ends or orphaned data.

“A FACTORY encapsulates the knowledge needed to create a complex object or AGGREGATE.”

That struck a chord. I’d never thought of factories as reassembly tools, especially when reconstituting objects from storage. Thinking of “creation” and “reconstitution” separately feels like a breakthrough in clarity.

“A REPOSITORY represents all objects of a certain type as a conceptual set (usually simulated).”

Treating storage like an in-memory collection isn’t just syntactic sugar, it’s a way to keep your business logic clean. No more SQL leaking into domain checks.

This trio of patterns — Aggregates, Factories, Repositories — reveals a theme: structure what matters and hide what doesn’t. The model should breathe freely without being weighed down by lifecycle details.

I found this chapter refreshing, not just for its concepts, but for how clearly Evans lays out the motivation behind each pattern.


Challenge for the Reader

  • In a system you’ve worked on, can you identify something that should have been an aggregate but wasn’t? What went wrong?
  • How do you handle the distinction between “create new” and “reconstitute from storage” in your current codebase?