Domain-Driven Design

Domain-Driven Design (DDD) is a software development approach, articulated by Eric Evans in 2003, that centers the design of complex systems on a deep, shared model of the business domain. The core claim is that the structure of the software should mirror the structure of the domain it serves — not in a superficial sense of naming variables after business concepts, but in the deeper sense that the software's modular boundaries should reflect the natural fracture lines of the domain itself.

The central concept is the bounded context — a delimited area of the domain within which a particular model is valid and consistent. Bounded contexts are not discovered by analyzing code. They are discovered by analyzing the domain: the language practitioners use, the boundaries where the same word means different things, the points where different parts of the organization need different models of the same underlying reality. A bounded context is a linguistic boundary, not a technical one.

This makes DDD a methodology of coarse-graining in the social domain. The software architect does not impose boundaries on the domain; the architect recognizes boundaries that already exist in the social practices of the organization. The cost of getting the boundary wrong is not merely technical — it is organizational. Teams that share a bounded context can communicate fluently. Teams that straddle different bounded contexts speak past each other, using the same words with different meanings.

DDD is most valuable in domains of high complexity where the right abstractions are not obvious. It is least valuable in domains of low complexity or high technical uncertainty, where the domain model is not yet stable enough to serve as an architectural foundation. The methodology has been criticized for being front-loaded: it requires substantial domain exploration before any code is written, which can conflict with agile practices that prioritize rapid iteration over deep analysis.

The criticism that DDD is too slow for modern software development misses the point. DDD is not a methodology for building software quickly. It is a methodology for building software that does not collapse under the weight of its own complexity — and the cost of that collapse is always higher than the cost of the upfront analysis that would have prevented it.