Apologies for not posting the Week 14 thread last week. We had a mix-up with scheduling and a couple of us were catching up on reading. Given that the two chapters flow nicely into each other, it worked out okay to talk about them together.

Chapter 14 – Maintaining Model Integrity

This chapter was more tactical than philosophical, which made for a slightly different reading pace. It dives into the patterns for preserving the integrity of large systems by managing how different models interact. I found the distinction between Shared Kernel and Customer/Supplier particularly useful — one speaks to tight alignment, the other to necessary detachment. The “Conformist” pattern also stood out, not because it’s ideal, but because it acknowledges the reality of working with upstream teams that you have no leverage over.

The big takeaway here is that not every part of a large system needs to follow the same model — and that’s not just okay, it’s necessary. But those boundaries must be made explicit and intentional.

Chapter 15 – Distillation

This one goes back to a more conceptual mode and touches on something we’ve probably all felt in some form: how do you keep the model manageable when the domain itself is sprawling? The chapter offers several techniques for “distilling” the model — finding the core and treating it as first-class.

The discussion on Generic Subdomains is a helpful lens. So many projects get derailed by spending too much time on things that don’t differentiate them. Evans’ anecdote about time zone logic being over-engineered (twice!) hit close to home.

I liked the framing that distillation is not just about clarity, it’s also a planning tool: where do you invest design energy, where do you allow good-enough code, what parts are safe to outsource, and what parts absolutely aren’t.

Some quotes that stuck with me:

“You’ll put a lot of effort into making your CORE distinctive, while keeping the rest as generic as possible.”

“Distillation does not operate only on the gross level of separating parts of the domain away from the core. It also means refining those subdomains, especially the core, through continuously refactoring toward deeper insight.”

From next week we’ll be entering the final leg of the book — the last few chapters build on these ideas and start wrapping things up.

Challenge for the Reader

  • In your current system, can you identify what belongs to the “core domain” vs. what’s a generic subdomain? Where are you over-investing?
  • Have you worked with an upstream team you had no leverage over? How did you handle the boundary — conformist, anticorruption layer, or something else?