Domain-Driven Design (DDD) helps you model an application in the language used by its domain, and is for modelers, developers, domain experts, and stakeholders who need to share an exact understanding of the system.
DDD is the practice of making the model adhere to the terms and definitions of the domain that the system serves. The domain is the business or activity area being modeled, such as vehicle sales, bread delivery, or insurance claims.
For example, a vehicle-sales model should use classes named Car and Brand when those are the terms used by people in that business. Naming the same classes A and B, then documenting elsewhere that A means a car, makes the model less readable and is not DDD.
Use a ubiquitous language
DDD aims to establish a ubiquitous language: a shared language used by developers, modelers, domain experts, and stakeholders when they discuss the system and its rules.
Use the same terms in:
- MDriven Designer class names, attributes, and association names.
- Business-rule expressions, including OCL.
- Discussions with the people who work in the domain.
- Documentation and user-facing labels where appropriate.
For example, if bakery staff say that a customer receives payment after staff hand the bread to the customer, model and discuss these concepts using those terms. Do not replace them with generic names such as Party, Item, and Transaction unless those generic terms are genuinely the language of the domain.
Model the domain, not an abstract substitute
A model is a simplified representation of real concepts. Its validity depends on whether it fulfills its purpose; there is no universally correct model independent of that purpose.
You can choose different structures for the same information. For example, Brand can be an attribute of Car, or it can be a separate class associated with Car. A separate Brand class avoids repeating a name such as "Plymouth" on every car and lets one brand object classify many cars. This choice can be better for that purpose, but it is not universally more correct.
DDD concerns the language of the model. A model can be used with model-driven techniques while using abstract, non-domain-specific names; that model is not DDD.
Start with domain people
Involve people who work in the domain. Existing documentation and IT staff alone may not describe the real work or the real problem, and domain participants need to be involved in changes that affect their work.
- Gather a representative group of domain people for a workshop.
- Identify triggers: people or parties that show interest in their work. Ask who calls, emails, visits, delivers, sends, or buys.
- Identify each persona's goals. For example, a customer may have the goal of getting a loaf of bread.
- Break each meaningful trigger-and-goal combination into the central steps needed to reach the goal. Aim for about five steps.
- Use these processes to identify important concepts, relationships, and rules for the model.
For the customer goal of getting a loaf of bread, the group may identify Fetch bread from shelf, Hand bread to customer, and Receive payment. These steps provide domain language that you can test against proposed class names and business rules.
DDD and MDriven
DDD defines the mindset for modeling; it does not prescribe what to do with a completed model. Model-Driven Development (MDD) focuses development on the model and uses it as the core definition for derived artifacts.
In MDriven, make changes in the model first. MDriven can use the model to generate and update parts of the domain layer, transform it into database schemas, and create ViewModels for application perspectives. Keep handwritten additions to the generated domain layer in partial classes.
DDD and MDD address different concerns:
| Concern | DDD | MDD in MDriven |
|---|---|---|
| Primary question | Are model terms and definitions those used in the domain? | Is the model the core definition from which other artifacts are derived? |
| Example | Name a class Car because domain people call it a car.
|
Change the Car class in the model before updating generated code and the database schema.
|
| Result | A shared language between technical and domain participants. | Model-first development and derived implementation artifacts. |
Use DDD when choosing what the model means and what it is called. Use MDD to apply that model consistently throughout the implementation.