05Splitting along the domain

Every multi-team product is divided somehow. The question is whether the division follows the technology, the existing organisation or the domain. Only the last one gives teams work they can finish on their own.

To make the discussion concrete, this essay uses a running example: a hospital system that manages blood transfusion, from the prescription of blood products to their administration at the bedside and the traceability that follows. It is a good test case. It is too large for one team, and an error in it can harm a patient.

Three common splits, and why they fail

• By technical layer. A front-end team, a back-end team, a database team. Each team is competent in its layer, but almost every feature crosses all three, so almost every backlog item requires all three teams to coordinate. This is the split Scrum in Name Only blamed for stories that never become increments.
• By component or technology. A team for the rules engine, one for the mobile application, one for the integration platform. Better than layers, but the components rarely match what users ask for, so features still span several teams.
• By availability. Work goes to whichever team has capacity. The code base becomes shared by everyone and owned by no one, and the central objects grow without limit.

Bounded contexts as team boundaries

A bounded context is, by definition, a part of the system with high internal cohesion and an explicit boundary. It has its own model, its own language and, ideally, its own data. Those are exactly the properties a team boundary needs. When a team owns a bounded context end to end, from interface to storage, most backlog items in that part of the domain can be refined, built, tested and released by that team alone.

In Team Topologies terms, such teams are stream-aligned: each one follows a flow of change in one part of the business. The rule of thumb is simple. A team may own several small bounded contexts, but a bounded context should never be split across teams. A shared model with two owners is a model with no owner.

Finding the seams

Bounded contexts are discovered, not invented. Several signals help find them:

• Language breaks. When the same word means different things to different experts, there is a boundary. In the transfusion example, a "unit" in the blood bank is a product with a donation number, a group and an expiry date; at the bedside, it is something to check against a patient's wristband before it is hung.
• Different experts. Biologists, blood bank technicians, prescribing physicians and nurses each own a part of the process and its rules.
• Different rates of change. Compatibility rules evolve with medical knowledge; billing rules change with tariffs; they should not be released together.
• Different constraints. Some parts are safety critical, others are not. Section 09 shows why that difference deserves a boundary of its own.

Alberto Brandolini's Event Storming is the most practical technique for this discovery. Domain experts and developers lay out, on a long wall, the business events of the process in time order. Clusters of events, changes of vocabulary and handovers between roles show the seams. A first session takes a day and costs far less than a year of teams organised along the wrong lines.