Apologies for being a day late in starting this thread — the discussion leader for this week had to step away due to unforeseen circumstances, and I’ve stepped in to get us back on track. We will be discussing Chapter 5: A Model Expressed in Software.
This chapter was fairly dense, covering four foundational building blocks of DDD: Entities, Value Objects, Services, and Modules.
What I appreciated about this chapter is how clearly it lays out the mental categories we need when shaping the model into code. We often throw these terms around, but here Evans gives them weight, tying them to purpose, not just structure.
Entities
I’ve always found the term “entity” a bit vague, but this chapter clarified it nicely. It’s not about what an object has, but who or what it is, over time. That shift is subtle but important. A customer who changes their email is still the same customer. The attributes move, but the identity holds.
Value Objects
These are my favorite kind of abstraction. When used well, they clean up so much noise. I liked how Evans emphasizes their immutability and disposability. You don’t manage them, you just use them. They carry meaning without needing to be tracked. It’s also where naming does a lot of the heavy lifting — for example, you want Address or Coordinates to feel precise and self-contained.
Services
This part helped me spot a few missteps in my own codebases. I’ve definitely seen domain logic crammed into entities just because we didn’t know where else to put it. Evans gives you that missing piece — logic that’s central to the domain, but doesn’t naturally belong to any one object, goes into a service. It’s a small clarification that can clean up a lot.
Modules
The idea that module boundaries shape how we think is one that I keep coming back to. It’s not just an organization trick. It’s a way of expressing which parts of the model belong together, and which don’t. In large systems, this is often the only thing keeping everything from blending into a mess.
Challenge for the Reader
- Did any of these concepts shift the way you’ve been thinking about structuring models?
- Have you encountered a messy value object or a leaky service class that made you rethink your boundaries?