Christophe MontagneInterim CTO · Advisory

Drawing the Lines/Part III · Beyond failure·3 min read

09Bounded contexts as risk boundaries

Concentrating rigour where harm can arise, and justifying segregation everywhere else.

In a critical product, not every line of code carries the same risk. A wrong colour on a report is an annoyance; a wrong compatibility decision can kill. Bounded contexts make it possible to draw the boundary between the two explicitly, and to concentrate rigour where the risk lives.

Rigour where it matters

Medical device regulation already thinks in these terms. IEC 62304 assigns software a safety class, A, B or C, according to the harm it could contribute to, and scales the required documentation and verification with that class. It also allows a software item to be classified lower than the system it belongs to, provided the manufacturer can justify the segregation between them. Without that segregation, the highest class spreads to everything.

A product whose model is one large, shared structure cannot justify any segregation. Every part can reach every other, so every change is potentially safety-relevant, and the whole code base must be treated at the highest level of rigour. The result is predictable: either the cost of change becomes prohibitive, or the rigour is applied on paper and not in practice.

A bounded context is a natural unit of segregation. It has an explicit boundary, its own model and its own data, and its relationships with other contexts are documented in the context map. If the safety-critical rules are gathered into a small number of contexts, those contexts can receive the full treatment, while the rest of the product proceeds with proportionate rigour.

Bounded contexts as risk boundaries in a transfusion system The compatibility and bedside administration contexts sit inside a dashed boundary marked safety-critical core and receive the highest rigour. Ordering and inventory feed into them from the left. Bedside administration publishes events to traceability and haemovigilance on the right, which in turn feeds billing, a generic context that can be bought. SAFETY-CRITICAL CORE Ordering Proportionate rigour Inventory Proportionate rigour Compatibility Highest rigour Bedside administration Highest rigour Traceability Proportionate rigour Billing Generic · bought events extract
Figure 2 · The transfusion example. Safety-critical rules are gathered into two bounded contexts that receive the highest rigour; the rest of the product is segregated from them by explicit, documented relationships.

The transfusion example

In the running example, two contexts hold the rules that protect the patient directly: Compatibility, which decides whether a blood product may be given to a given recipient, and Bedside administration, which guides the final identity and compatibility checks before the product is administered. They are kept deliberately small. Ordering, Inventory and Traceability matter and are verified properly, but a defect in them is caught by the checks in the critical core. Billing is a generic subdomain, bought rather than built, and isolated behind an extract.

The boundaries are not only drawn on a diagram. Each critical context owns its data, exposes a narrow interface and accepts information from other contexts only through explicit translation. That is what makes the segregation argument credible to an assessor, and what keeps it true as the product evolves.

Core domain and critical domain

DDD asks organisations to invest their best people in the core domain, where the business differentiates itself. In critical products, a second category deserves the same treatment: the contexts where failure causes harm. The two often overlap but are not always the same. A bank's differentiating core might be its pricing; its critical core is the ledger and settlement. Both need the strongest team and the deepest modelling. Making the distinction explicit, in the context map and in team assignments, prevents the critical parts from being treated as plumbing.

Section takeaways

  • A bounded context is a natural unit of segregation, which lets rigour be concentrated where the risk lives instead of spread across the whole product.
  • Keeping the safety-critical contexts small, with their own data and narrow interfaces, makes the segregation argument credible and durable.
  • Critical contexts deserve the same investment as the core domain, even when they do not differentiate the business.