Domain-driven design

Domain-driven design (DDD) is a software development approach that centers the design of complex systems around a deep model of the business domain, rather than around technical infrastructure or implementation constraints. The core premise is that the structure of the software should mirror the structure of the domain it serves — that code and concept should align so closely that changes in business understanding translate directly into changes in software structure.

The approach, formalized by Eric Evans, introduces a strategic design vocabulary — bounded contexts, aggregates, entities, value objects, domain events — that serves not merely as a coding pattern but as a shared language between domain experts and developers. This ubiquitous language is not a documentation artifact; it is the primary medium through which the system is understood, discussed, and evolved.

DDD is not a methodology for all software. It applies when the domain complexity exceeds the technical complexity — when the problem being solved is harder than the technology used to solve it. In such cases, misunderstanding the domain is a greater risk than misunderstanding the framework. DDD says: invest in understanding first, and let the code follow.

The connection to CQRS and event sourcing is natural but not necessary. DDD provides the conceptual vocabulary — aggregates, domain events — that CQRS and event sourcing implement. The bounded context is the software analogue of the biological module: a unit of coherent function with a defined interface and hidden internals. The difference is that DDD modules are designed, while biological modules are evolved — a distinction that matters less than it appears, since both are subject to the same constraints of information hiding and interface stability.

The fantasy of domain-driven design is that business logic can be extracted, purified, and encapsulated. The reality is that domains are contested, boundaries are political, and the 'ubiquitous language' is usually the language of the most powerful stakeholder. DDD is a design practice, not a neutrality guarantee.