Learning Domain-Driven Design — Chapter 3

Vova praises the table at the end of the heuristics chapter — the first decision tree he has seen for tactical patterns specifically — though he doubts you can walk into a team and just point at a branch: Vlad himself writes that it is not the whole truth but a set of starting points. Ilya likes the critique of "it depends": instead of "here are the approaches, apply them as the situation dictates" the author gives a soft rule that may be broken. Alexander has seen more complex charts — a map of some fifty patterns, from business to technical — and believes the value is not in the picture but in everything you have read falling into place: you see where the decision points are. That is why decisions should be recorded with their reasons — which subdomain, what the aggregates look like — so that half a year later it is clear what changed and whether to revisit; and never justify a choice with "that is what the book says", or, as Vova jokes, colleagues will hit you over the head with it.

Ilya adds the testing strategy, which appears only here: the pyramid, the diamond, and the inverted pyramid — shares of unit, integration, and end-to-end tests for different kinds of business logic. Alexander describes how he reads books: he builds his own decision trees and checks them against the author's, and in his 2021 article on choosing a mobile technology he drew a similar tree of questions — what you need, who you have in the company, where you are heading; Ilya draws a mind map for every chapter. On the size of a bounded context the author answers "of course, it depends" but adds that size is the last criterion: start with wide boundaries, keeping in one context the core subdomains that change together often, with generic ones next to them. Alexander reminds why: the core is complex and its logic is implicit — you dig and fall down the rabbit hole like Alice — and contexts carved too finely are very hard to merge later.

The chapter on evolution, Alexander says, is less about architecture than about business: four kinds of change — in the business domain, organisational, in domain knowledge, and growth. Subdomains change type: supporting can become core, as AWS did at Amazon, and core can degrade into generic, as Garmin's navigation did after smartphones and Google Maps; the tactical pattern then has to change too. Transaction Script to Active Record is easy, and Active Record to a domain model is spelled out step by step: find the value objects, make setters private so the compiler reveals every modification point, move the logic into an aggregate method, reference external aggregates by identity, and decide where strict consistency is required. The trigger is duplicated modification logic in several places. From a domain model to an event-sourced one there are two routes: generate an approximate history with fake events or record a single migration event with the current state; Alexander prefers the second — transparency beats confidence — while admitting he once wanted to print and burn the code of a system he retired after two years.

Organisational changes: a partnership between teams falls apart when they go remote and gets replaced by customer–supplier; a large team splits into credit and debit products, the shared backlog diverges, and the context integration has to be pulled apart. Moving to separate ways fits generic and supporting subdomains — sometimes buying a market solution is cheaper than remaining a customer of an internal supplier; Ilya recalls lending being split into small and medium business, where writing their own turned out cheaper than maintaining the shared code. Alexander sees Conway's law here: change the communication structure and the design changes. Domain knowledge argues for wide contexts: a team that split a seemingly clear domain into microservices found that strict consistency had to cross boundaries, and after the MVP the services had to be glued back together. Growth is a sign of a healthy system, but new logic gets stuffed into existing aggregates and a big ball of mud results; the DDD tools — subdomains, contexts, value objects, aggregates — act as boundaries whose violation shows it is time to fix things.

Alina walks through EventStorming: a brainstorm that is less technical than about the business, with people from different processes — designers, analysts, developers; about ten people offline, no more than five online. You need a large board, sticky notes of several colours, markers, and food: a session takes hours, sometimes days. The steps: orange notes with events in the past tense that everyone sticks anywhere; arranging the timeline; pink diamonds for pain points; pivotal events as future context boundaries; blue commands with actors; automation policies where a command is triggered by the system rather than a person; green read models; external systems; then commands and events are grouped into aggregates — their public interface — and into contexts. Alexander adds the facilitator role: he trained for it with the method's populariser in Russia, while its creator Alberto Brandolini presents it in forty minutes at conferences; Vlad runs a big-picture session first, then separate sessions per process.

The final chapter dispels myths: DDD is not only for greenfield — on the contrary, brownfield projects gain the most if it is adopted gradually, without a big bang. The core domain in legacy is easy to find: it is the code everyone is afraid to touch. Alexander likes the chapter as a manual for a technical leader entering an unfamiliar company: understand the business, its customers and competitors, identify the subdomains, work out which tactical patterns are in use and whether they went stale over three years, build a context map — and the ideas for improvement follow. The modernisation strategy is small steps: logical boundaries first, in components and namespaces, then physical ones where a separate release rhythm is needed; the tactic is the strangler fig, with a new service gradually intercepting the old one's requests; and promoting the ubiquitous language all the way into the code. The main thesis is not DDD for its own sake: the business domain should drive the design, and the approach is better sold by example than by zeal. Next time — part four, and the session after that — a conversation with the author.