Christophe MontagneInterim CTO · Advisory

Drawing the Lines/Closing

Conclusion

What the two disciplines achieve together that neither achieves alone.

Scrum and Domain-Driven Design answer different questions. Scrum asks how a team learns and delivers under uncertainty. DDD asks what the team is learning about, and where one part of that knowledge ends and another begins.

For a small product built by one team, the difference hardly matters; a good team handles both questions in its daily conversations. As products grow beyond one team, the second question becomes structural. The lines drawn between teams decide how much autonomy survives, and DDD's bounded contexts and context maps are the most principled way to draw them. The result is what large products need: sub-projects as independent as possible, contributing to one product, under one Product Goal.

As products become critical, the second question becomes a matter of evidence and endurance. Bounded contexts become risk boundaries, the ubiquitous language makes requirements testable and traceable, aggregates and events turn rules into guarantees, and anticorruption layers keep the model intact while the world around it changes. Scrum provides the rhythm that keeps all of this current, sprint after sprint, instead of reconstructed before each audit.

Neither discipline replaces the other, and both can be practised in name only. Practised for their purpose, together, they produce what neither achieves alone: a product that can grow, be proven and last.

Key takeaways

  1. Scrum is deliberately silent on structure. It does not say how to divide a product between teams or how to keep its meaning consistent. DDD does.
  2. The two share their roots. Empiricism, close work with domain experts and working software are common ground, so they combine with little friction.
  3. Team boundaries are architecture. By Conway's law, dividing the teams divides the system. Divide along bounded contexts, with one owning team per context.
  4. Context maps reduce coordination by design. Each dependency gets an explicit relationship, and each relationship implies a way of working between teams.
  5. Unity at product level, autonomy at context level. One Product Goal, backlog and Definition of Done; separate models, languages and designs.
  6. Bounded contexts are risk boundaries. They let critical products concentrate rigour where harm can arise and justify segregation elsewhere.
  7. A precise language is evidence. When requirement, test and code share the same words and rules, traceability and verification become by-products of design.
  8. Sustainability comes from boundaries. Known change reach, anticorruption layers and a living model keep critical products changeable for decades.
  9. Both disciplines drift the same way. Keep the purpose (goals, inspection, conversation with experts), and the practices will keep their meaning.