Domain-Driven Design: Tackling Complexity in the Heart of Software

Evans's argument is that software which resists maintenance is usually software whose model has drifted from the business it is meant to represent. The cure is ubiquitous language — the same words in code, in meetings and on whiteboards — and bounded contexts where models are allowed to differ without pretending they agree. For product direction this is the clearest technical articulation of why vocabulary matters. When a team says "user" and means four different things in four different meetings, no amount of planning will save the codebase. Domain-Driven Design gives a discipline for noticing that drift before it becomes structural.