A status called returned
The old software had one word for a machine coming back from a building site: returned. The hire planners at the equipment rental firm never used it. They said a builder had off-hired a digger, meaning the builder had called to say the job was done; at this firm, the hire stops being charged from that call. Days later a lorry collected the digger and brought it back to a depot. The software folded both into one status, so on a Friday afternoon an off-hired digger showed up on a planner's screen as free for Monday, and she promised it to another builder. On Monday it was still standing on the first site, 40 km away, waiting for a lorry.
A review that checked the code only against itself would have found nothing wrong. The code did what it said; what it said was not what the business meant, because somewhere between the planners' words and the developers' a distinction fell out. Strategic domain-driven design (DDD) starts with exactly that gap, and with a question the firm had to answer before fixing anything: which parts of the business deserve that much attention?
The business before the software
The firm hires out 2,400 machines, from mini excavators to generators, out of 11 depots, and eight developers are replacing software that grew out of a booking spreadsheet. The business they serve takes bookings, decides which machine goes to which site, moves machines between depots, services and inspects them after each hire, delivers and collects them, sends invoices and pays its staff. That list is the problem space: what the business does, with or without software. Each coherent area of it, with its own experts and its own rules, is a subdomain, and it would exist if no one wrote a line of code. The solution space is what the team builds in answer. A subdomain is a part of the business, found by listening to it; a bounded context is a part of the software inside which one model and its language hold, drawn by the team and redrawn as it learns the business.
Where the best people go
Builders choose this firm because a digger ordered in the morning is on site the same day, and that depends on hire planning: promising machines to jobs, knowing when each one comes back, moving units between depots before a shortage. The firm lives on utilisation, the share of days a machine is out earning, because a digger in the yard costs nearly as much to own as one on hire. Hire planning is the core subdomain, the part where the firm differs from its competitors and where better software is better business. The firm chose to give it its strongest developers and the longest hours with the experts, and to write and own its code.
The depot workshop services and inspects every machine that comes back, by checklists and turnaround rules no product on the market knows. The business needs it and it is the firm's own, but no builder picks a hire firm for its inspection workflow. That makes it a supporting subdomain, and the firm chose to build it with less investment than the core, through a smaller team. Transport, the lorries that deliver and collect, sits in the same place.
Invoicing, payroll and staff logins are generic subdomains: every company has them, good products already solve them, and doing them better wins no customers. The firm chose to buy them, and every week a developer spends on a homemade payroll comes out of hire planning.
Each card is a part of what the firm does, not a service to deploy. The arrows carry facts between the parts, named in the experts' words.
These labels are a judgement about the business, not a property of the activity. If competitors started winning work with turnarounds measured in hours, the workshop's scheduling would move toward the core, and the effort would have to move with it.
Words that hold in the code
The returned status was a core problem, so the core is where the developers sat down with the planners first. What they built there is a ubiquitous language: one shared, precise vocabulary that the developers and the domain experts, here the hire planners, work out together and then use everywhere, in conversation and just as strictly in the code and its tests. The new model has an offHire() operation and a separate collect(). One test is named off-hiring a machine does not by itself make it available to another site, a sentence a planner can read and confirm.
The language is built, not handed over. A developer proposes a word, a planner says that is not what happens, and the model changes along with the word. When a class in the model gets a name that no expert would ever say, the code has started a language of its own, and meetings go back to translating: the road that led to returned.
How many machines on Monday?
The next trouble showed up in a conversation. The team asked the planners and the workshop lead the same question: how many machines are available on Monday? The planner said six: builders hire a kind of machine, a 1.5-tonne excavator, not a particular one, and she counted the units of that kind she could promise. The workshop lead answered unit by unit, because the workshop decides whether one particular machine may leave the yard: of the depot's eight 1.5-tonne excavators, 1187 could not go out, because its hydraulic inspection was due, and neither could 1203, which had come back with a split hose.
Both answers are correct. The planner counts machines of a kind; the workshop tracks one machine by its serial number.
For the planner, a machine is a kind: interchangeable units, counted and booked by size. For the workshop, it is one unit with a serial number, engine hours and an inspection certificate that expires. Both are right, and each group's rules hang on its own meaning, so neither can be asked to adopt the other's. A word that means different things to two groups of experts is the signal that the language has stopped being one language, and the first place to look for a boundary in the software. Drawing that boundary is the subject of Bounded Context; how the two sides then trade facts is the subject of Context map: how bounded contexts relate.
Not every double meaning calls for a boundary. When both meanings belong to the same experts' work, a second word inside the one language is usually enough, and that is all off-hire and collected needed.
Where the language changes, on a Grid
The Bounded Context Challenge has a requirement that is this article's subject: show where the ubiquitous language changes. Take a word that two groups of experts use differently, like machine, and put each meaning in the context of the experts who use it, named in their words, say an Aggregate for the planners' kind of machine and an Entity for the workshop's unit. Label the edge between the two contexts with the translation, and write on the Grid whose meaning each one is. If you cannot name two groups of experts with different rules for the word, you have probably found a word that needs sharpening, not a boundary.