Recent Reading June 2025

This time around it’s a talk that I have watched a few times now because it has so many good bits of wisdom in it.

Domain Driven Design: The Good Parts

A study of using domain-driven design to build systems for Texas government agencies. Uniquely, the speaker got to do a do-over of the same system(ish) and learn. What stood out to me:

Bounded Contexts as the most important concept of DDD.

• When you ask people “what is the most important thing for you” and they all give you a different answer, that’s a good indicator that they operate in different bounded contexts.
• Ubiquitous language is a tricky thing. And if people are not agreeing on the language, mayhaps that’s another sign that they operate in different bounded contexts.
• Number of different bounded contexts can be essentially used as a proxy for complexity of a system. The more bounded contexts, the more complex the system is.

Ditch architectural patterns until they emerge. (And CQRS is very nice.)

• Ultimately our customers do not care what pattern we use to access data, it won’t bring them extra value. (Though if we do build ourselves into a corner, they will care that we cannot deliver functionality or fix bugs fast enough.)
• This pragmatic approach matches my experience, and I feel that it’s becoming a part of the discourse more and more.

When you build the software to model existing process and needs, your users will be happier.

On its surface this seems like such an obvious truth, and then again… I remember being a young programmer thinking that people should ditch their existing approach and just use my, obviously better, approach.