Domain-Driven Design (DDD) is a software development philosophy that centers the codebase around a rich, explicit model of the business domain, ensuring that software structure and language mirror real-world concepts and rules.
Domain-Driven Design, introduced by Eric Evans in his 2003 book of the same name, is an approach to building complex software by placing the business domain at the heart of every design decision. The core idea is that the structure and language of the code should closely match the business problem it solves. Developers and domain experts collaborate continuously so that the software model accurately reflects real-world rules and workflows.
A cornerstone of DDD is the Ubiquitous Language — a shared vocabulary co-created by developers and domain experts that is used consistently in conversation, documentation, and code. This eliminates the costly translation layer between 'what the business says' and 'what the code does.' For example, if the business calls it an 'Order Confirmation,' the class, method, and event in code should use exactly that term, not 'PurchaseAck' or 'BuyRecord.'
Large domains are divided into Bounded Contexts — explicit boundaries within which a particular model and its Ubiquitous Language are valid and consistent. Different Bounded Contexts can have overlapping concepts (e.g., 'Customer' in a Sales context vs. a Support context) that are intentionally modeled differently to suit each context's needs. Context Maps define how Bounded Contexts relate to and communicate with each other, preventing model corruption across boundaries.
DDD provides a set of tactical patterns for implementing the domain model: Entities (objects with a unique identity, like an Order), Value Objects (immutable descriptors with no identity, like a Money amount), Aggregates (clusters of entities and value objects treated as a single unit with a root), Domain Events (records of meaningful business occurrences), and Repositories (interfaces for persisting and retrieving aggregates). These building blocks encode business rules directly in the domain layer rather than scattering them across services or databases.
Developers hold regular sessions — often called Event Storming workshops — with domain experts to discover domain events, commands, and aggregates before writing a single line of code. The resulting model drives the folder structure, class hierarchy, and API design of the application. Persistence, UI, and infrastructure concerns are deliberately pushed to the outer layers of the architecture (often combined with Hexagonal or Clean Architecture), keeping the domain model pure and testable.
DDD is not appropriate for every project — applying it to simple CRUD applications adds unnecessary complexity and overhead. The most common pitfall is an Anemic Domain Model, where domain classes are mere data containers with all logic in service classes, which violates DDD's intent. Start by identifying your core domain (the area of highest business value and complexity) and apply the full rigor of DDD there, while using simpler patterns for less critical sub-domains.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app