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?