The article “An Introduction to Domain-Driven Design” by David Laribee (
https://msdn.microsoft.com/en-us/magazine/dd419654.aspx) provides a great introduction to Domain-Driven Design (DDD). The definitive book for this topic, “
Domain-Drive Design: Tackling Complexity in the Heart of Software”, by Eric Evans, can be a bit overwhelming (especially if one has never been exposed to DDD before), but this article is a great starting point for people wanting to learn more about Domain-Driven Design. The author himself describes this article as a “gentle introduction to designing and evolving rich domain models”. The following is a brief summary of the topics covered in this article.
Model-Driven Design
The software we write is just a model of the system or business process we are automating. The model in everyone’s head and the model that gets implemented in software is never exactly the same. The concept of modifying software over time to more closely match the true model is model-driven design.
Ubiquitous Language
Terminology used by experts in any domain to describe concepts in that domain is called the Ubiquitous Language. Class names, variable names, etc. in the software should use terms from this Ubiquitous Language. Both the business experts and the programmers should be using the same language to describe the business.
Bounded Context
Most enterprise systems have course-grained areas of responsibility. In DDD these areas are called Bounded Contexts. A context map is used to diagram the Bounded Contexts and describe how they relate to one another. Each Bounded Context can have its own unique Ubiquitous Language.
Anti-Corruption Layers
An Anti-Corruption Layer is a DDD pattern that is used to prevent non-domain concepts from leaking into a model. A repository or data access layer is an example of an Anti-Corruption Layer. They keep SQL or other persistence details out of your model.
Entities
An Entity is a noun (i.e. a person, place, or thing) that has both an identity and a lifecycle. For example, a person has a name, a car has a VIN, a city has a name, etc. Also, a person has a birthday and eventually a day they died, a car has a manufacture date, etc.
Value Objects
Value Objects are descriptors or properties that do not have an identity, they simply describe something about an entity. Value Objects are also immutable (i.e. they do not change value once they are created). An object representing the value $35.75 USD is an example of a Value Object (i.e. a decimal value 35.75 and an indicator the value is in US dollars).
Aggregate Roots
An Aggregate is a cluster of associated objects (e.g. entities, value objects, etc.) that are treated as a unit. An Aggregate Root is the single, specific entity in the Aggregate that objects outside the scope of the Aggregate are allowed to hold a reference to. Objects inside the Aggregate are allowed to refer to each other, but objects outside of the Aggregate must go through the Aggregate Root to access objects in the Aggregate.
Domain Services
Domain Services are classes use to represent operations or processes that do not have an identity or lifecycle in the domain. They are typically named after verbs or business activities defined in the Ubiquitous Language. A “funds transfer” service that withdraws money from one account and deposits it into another account is an example of a Domain Service.
Repositories
Repositories are used to retrieve and store entities. They prevent database or persistence concepts (e.g. SQL statements, stored procedures, etc.) from getting in the model. They are an example of an Anti-Corruption Layer.
DDD Resources
DDD combines many good object-oriented programming principles, design patterns, software development practices, techniques, and philosophies. The following resources are good places to learn more about DDD:
