11Built to last

A critical product is rarely finished. Its domain evolves, its regulations are revised, its technology ages and its teams change. Sustainability is the ability to absorb all of that without losing the guarantees the product was built on. DDD contributes to it in three ways: it limits the reach of change, it protects the model from what it does not control, and it preserves understanding beyond the people who first had it.

Change with a known reach

When a new medical guideline modifies a compatibility rule, the question every regulated team asks is: what else does this affect? In a system without boundaries, the honest answer is "potentially anything", and the impact analysis, the regression testing and the re-verification grow accordingly. Over the years, each change becomes more expensive than the last, until the system reaches the state Brian Foote and Joseph Yoder called the big ball of mud.

With bounded contexts, most changes stay inside one context. The impact analysis starts from the context map: if the change does not alter a published interface, other contexts are unaffected by construction. Verification can focus on the context that changed and on the contract tests at its boundaries. That is what keeps the cost of the hundredth change close to the cost of the tenth.

Protection from what you do not control

Critical products depend on systems their builders do not own: hospital information systems, laboratory instruments, payment networks, third-party libraries. IEC 62304 calls the latter software of unknown provenance, or SOUP, and requires its risks to be assessed and controlled.

The anticorruption layer is DDD's answer to all of these. Each external model is translated at the boundary into the context's own language, and nothing beyond the translation layer depends on its quirks. When the hospital replaces its patient administration system, or a library must be upgraded for security reasons, the change is confined to one translation layer, which is also the natural place to verify the external component's behaviour and document its risk controls.

The same principle supports modernisation. A legacy system can be replaced one bounded context at a time, the new context taking over its part of the domain while an anticorruption layer keeps the old and new models apart. Martin Fowler named this approach the strangler fig. It turns a risky "big bang" migration into a sequence of increments, each of which fits naturally into Scrum's sprint rhythm.

Understanding that outlives the team

Over a twenty-year life, nobody who designed a system will still be there to explain it. Documents age, and comments drift from the code. What survives best is understanding embedded in the code itself: names that mean what the domain experts mean, rules gathered in the place they apply, boundaries that say what belongs together.

A well-kept ubiquitous language and context map act as the product's institutional memory. A new team member can learn the domain from the code, and a new domain expert can read the executable scenarios. This is the deeper meaning of the Agile Manifesto's call for a pace that can be sustained indefinitely: it is not only the pace of the people, but also the capacity of the system to keep being understood and changed.

Keeping it that way is continuous work. Evans calls it refactoring towards deeper insight: each time the team understands the domain better, it reshapes the model to match. Scrum provides the rhythm for it, and section 12 shows where it fits.