12Weaving DDD into the Scrum cycle

Where each DDD activity lives in Scrum's loops, the Definition of Done, and who owns the context map.

Part IV

Putting it into practice

Parts II and III made the case. Part IV turns it into practice, and warns against the drift that threatens DDD as much as Scrum.

DDD is not a phase to complete before Scrum starts, nor a separate process running beside it. It works best woven into Scrum's existing loops, with strategic design at the product level and on a longer cadence, tactical design inside each sprint, and the ubiquitous language present everywhere.

DDD at every level of the loop

Scrum in Name Only described Scrum as a set of nested loops. Each loop is a natural home for a different part of DDD.

When	Scrum moment	DDD activity
Product inception	Forming the Product Goal and the first teams	Big-picture Event Storming; first context map; identify core and critical subdomains; align teams with contexts
Every quarter or release	Product Goal and release planning	Review the context map against the flow of work; plan strategic refactoring; adjust team boundaries if needed
Continuously	Product Backlog refinement	Write items in the ubiquitous language, with domain experts; express rules as examples and scenarios; place each item in its context
Every sprint	Sprint Planning	State each context's contribution to the Product Goal; flag any item that changes a boundary
Daily	Development	Model with experts, apply tactical design, refactor towards deeper insight
Every sprint	Sprint Review	Domain experts validate behaviour and language; disagreements on meaning become backlog items
Every sprint	Sprint Retrospective	Inspect friction at the boundaries: waits on other teams, recurring confusion over terms

Table 7 · Where DDD activities live in the Scrum cycle.

The Definition of Done carries the model

The Definition of Done is the lever that keeps the model alive. A few additions are usually enough: new or changed terms are reflected in the context's language, scenarios have been reviewed by a domain expert, invariants are covered by tests, contract tests pass at every boundary the item touches, and the context map is updated if a relationship changed. In regulated products, the same Definition of Done links each item to the requirements and risk controls it affects.

The context map needs an owner

Inside a bounded context, the owning team is accountable for the model. Across contexts, someone must be accountable for the context map: the boundaries, the relationships and the shared vocabulary at the seams. This is the architecture accountability that Scrum in Name Only argued every organisation must assign explicitly.

In practice it rarely belongs to a single person working alone. A common arrangement is a product-level architect who models and codes, working with a community of practice made up of one hands-on modeler from each team. They meet on a regular cadence, review the context map, and bring proposed boundary changes to the Product Owner as backlog items, competing for capacity like any other work.

A starting sequence

For a product already running with several teams, a modest sequence is enough to begin:

Run a one-day Event Storming session on the main business flow, with domain experts and members of every team.
Draw the context map as it is today, not as it should be, including the shared structures nobody owns.
Compare it with the team structure and the cross-team items of the last few sprints, and name the worst mismatch.
Fix that one boundary first, typically by giving a context a single owner or by introducing an anticorruption layer.
Add the language and boundary criteria to the Definition of Done, and review the map every quarter.

Section takeaways

Strategic design belongs to the product-level loops; tactical design and the language belong to every sprint.
The Definition of Done is what keeps the model, the language and the context map current.
The context map needs an explicit owner, usually a hands-on architect working with a modeler from each team.