A long time ago in a galaxy far, far away….
When I first
crashed against made contact with Domain Driven Design back in 2014, it wasn’t exactly love at first sight: the topic was intriguing yet a bit obscure, not very well known in the PHP circles, and definitely out of my comfort zone.
Slowly but steadily, I started to better understand what Domain matters were about, and why it’s a good idea to keep them apart from Infrastructural concerns: how can implementations follow business needs and not the other way around, and how to refrain from over-engineering by focusing on business value first.
By Favoring clarity over techiness, technology started to look more like a part of the solution to implement rather than one of the problems to be solved.
Despite study and practice though, the lack of Strategic Design knowledge started to become a problem: the complexity of software I worked on kept growing while my approach wasn’t scaling just as fast.
You can’t always take months to read up on a subject like DDD, and yet you still want to put DDD to work as soon as possible.
With summer vacations finally about to start I had a little bit of time at hand, so I decided to pick up what it’s possibly the most accessible book on the topic for someone who, like me, already had the chance to put DDD to practice in a few projects and now needs some broader perspective and direction to walk the next steps.
Enter Domain-Driven Design Distilled
The book has 7 chapters covering four areas:
- Introduction: What DDD can do to improve a team’s workflow and design
- Strategic Design: Bounded Contexts, Subdomains and Context Mapping
- Tactical Design: Aggregates and Domain Events
- Management Tools: Event Storming, DDD in Agile Projects, Modelling, Estimations
This section provides the philosophical foundation for the book by briefly considering the cost of introducing DDD and how it can help with fixing some recurring problems lots of teams and companies have:
Developers are too wrapped up with technology and trying to solve problems using technology rather than careful thought and design.
The database is given too much priority, and most discussions about the solutions center around the database and a data model rather than business processes and operations.
Developers don’t give proper emphasis to naming objects and operations according to the business purpose that they fill.
Developers often perform persistence operations in the middle of business logic.
If you’re familiar with the practice, you’ve probably seen those situations before: DDD offers design tools and effective knowledge acquisition techniques that help you and your team move past them and deliver good quality and effective software.
The three chapters on Strategic Design are possibly the most important one to me, as they cover tools and techniques to divide and conquer the Problem and the Solution Spaces by identifying Subdomains, implementing Bounded Contexts, and mapping them to form a cohesive and well encapsulated system, all by providing concise theory and solid examples: exactly what I wanted.
[You could start thinking of a Bounded Context] as part of your problem space. However, as your model starts to take on deeper meaning and clarity, your Bounded Context will quickly transition to your solution space, with your software model being reflected as project source code.
A Bounded Context is where a model is implemented, and you will have separate software artifacts for each Bounded Context.
Subdomains can be used to logically break up your whole business domain so that you can understand your problem space on a large, complex project.
Another way to think of a Subdomain is that it is a clear area of expertise [...]
I especially liked the explanation of the Context Mapping patterns, an important set of techniques used to connect otherwise segregated Bounded Context. The book covers seven of them: Shared Kernel, Customer-Supplier, Conformist, Anticorruption Layer, and Open Host Service.
This section -composed of two chapters- covers some of the most important tactical design patterns: Aggregates, Entities, Value Objects and Domain Events.
I found the way the author explains the concepts to be very effective by first introducing the the ideas quickly and clearly, and then by driving the reader through a series of modelling examples to show how Aggregate and Transactions modelling could work in real life. I also found the references to Functional Programming and the Actor Model helpful to clarify some doubts and set the path for further learning.
Both the Aggregate and the Domain Events chapters pack a lot of value and useful insights and are definitely recommended.
what I mean by “transaction” is how modifications to an Aggregate are isolated and how business invariants —the rules to which the software must always adhere— are guaranteed to be consistent following each business operation.
Possibly the most difficult part to put to practice if you -like me- are a developer who has no control over an organization’s set of processes, but nonetheless extremely valuable.
We need to crunch and distill knowledge in great quantities and produce a design that is effective in meeting the strategic needs of an organization.
In order to reach such goal, the author spends most of the chapter explaining Event Storming, a powerful methodology for quick Knowledge Acquisition that brings all the interested parties to the
table wall for intense yet playful sessions of Domain Discovery and modelling. Fun, Valuable, and very good fit for DDD teams when it comes to understanding the Business Domain.
The chapter closes by mentioning a few other useful tools -like SWOT- and estimating techniques that can be used alongside Event Storming to improve DDD implementations even further.
In a nutshell
I really enjoyed reading Domain-Driven Design Distilled as it covers a lot of important topics such as Bounded Contexts, Aggregates and Event Storming. It helped me to understand Subdomains, and how to do Context Mapping; How to properly define Transactions around Aggregates and how to model well-balanced Domain Events. It also briefly described how concepts I know little about such as Reactive Models and Functional Programming relate to DDD, all in a concise and very readable format.
Now I feel confident enough to tackle the Red Book and make the next step in the wonderful world of DDD.