Domain-Driven Design (DDD) contains a consistent set of concepts and terms, which need to be understood in order to apply DDD successfully. This glossary provides a brief overview of the most important terms. Rather than providing some own wording, the main DDD authors will speak for themselves.
The terms are just listed in alphabetical order, with links to relevant sources for further reading.
A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to on member of the Aggregate, designated as the “root”, a set of consistency rules applies within the Aggregate’s boundaries.
[Evans, 2003, p. 353]
Each Aggregate is composed of one or more Entities , where one Entity is called the Aggregate Root. Aggregates may also have Value Objects composed on them.
[Vernon, 2016, Chapter 5]
A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
Inside the boundary, all terms and concepts have specific meaning, and the model is consistent.
Outside the boundary, the same terms may have different meanings.
[Evans, 2003, p. 336]
DDD’s strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It’s usually worthwhile to depict these using a context map.
The Context Map […] is […] a simple diagram that shows the mappings between two or more existing Bounded Contexts.
[Vernon, 2016, p. 87]
This is the central term for the whole DDD approach, with a surprisingly simple definition. “Domain” is just what we deal with, on the business side of our software project. Evans’ definition centers around the user (and her/his perception).
The subject area to which the user applies a program is the domain of the software.
The domain is the sphere of knowledge and activity around which the application logic revolves.
[Evans, 2003, p. vi]
Vernon puts it this way:
A Domain, in the broad sense, is what an organization does and the world it does it in. Businesses identify a market and sell products and services. Each kind of organization has its own unique realm of know-how and way of doing things. That realm of understanding and its methods for carrying out its operations is its Domain. When you develop software for an organization, you are working in its Domain. It should be pretty obvious to you what your Domain is. You work in it.
[Vernon, 2016, p. 43f.]
In DDD, Core Domains, Supporting Domains, and Generic Domains are used to categorize different parts of a business.
Core Domains represent the central and unique business logic of a business. They encapsulate the primary functionalities that distinguish your business from competitors. This is what you need to do yourself, rather than buying it off the shelf, or using a generic solution. Focusing on Core Domains ensures that you effectively address the core needs and goals of your users or organization.
Supporting Domains, on the other hand, provide essential but non-unique functionality. These domains often include common features such as user authentication, logging, or payment processing. While critical for a business’s overall operation, they don’t directly contribute to your software’s distinctiveness. Categorizing them as Supporting Domains allows you to reuse existing solutions or libraries, saving development time and resources.
Generic Domains encompass universally applicable concepts found in many businesses, such as email, document management, or reporting. These domains are typically managed using well-established technologies and frameworks, allowing you to rely on proven solutions and focus your efforts on Core and Supporting Domains.
The benefit of distinguishing between these domain types lies in efficient resource allocation, maintainability, and scalability. Prioritizing Core Domains ensures that you allocate resources where they matter most, making your business competitive. Meanwhile, Supporting and Generic Domains can be handled more efficiently by leveraging existing solutions, reducing development costs and effort.
A very detailed description of these domain types can be found in the article “Core Domain Patterns. Strategy, Architecture, Continuous Delivery, and DDD” by Nick Tune.
Large systems are often decomposed into multiple subdomains, each representing a distinct area of the overall Domain. This decomposition is specific to the project at hand - it may be different for another project.
A bounded context defines an explicit boundary within which a model applies. Usually you can translate bounded contexts as the boundary of a software development team’s responsibilities. A subdomain should therefore not be split between several bounded contexts. A bounded context would ideally cover one subdomain, but (especially in larger projects) it might contain several subdomains.
Vernon introduces the distinction between problem space and solution space, which is also helpful in understanding the difference between subdomain and bounded context.
The problem space is the parts of the Domain that need to be developed […]. Thus, your problem space is […] the Subdomains it must use. […] The solution space is one or more Bounded Contexts, a set of specific software models. That’s because the Bounded Context is a specific solution, a realization view, once developed. The Bounded Context is used to realize a solution as software.
[Vernon, 2016, p. 56f.]
[Projects must pay] proper attention on Subdomains in their problem space and Bounded Contexts in their solution space.
[Vernon, 2016, p. 82]
A Domain Event is a record of some business-significant occurrence in a Bounded Context.
[Vernon, 2016, p. 99]
Your Domain Event type names should be a statement of a past occurrence, that is, a verb in the past tense. [[…] It’s a combination of the Domain Event’s name and its properties that fully conveys the record of what happened in the domain model.
[Vernon, 2016, p. 101]
An Entity models an individual thing. Each Entity has a unique identity in that you can distinguish its individuality from among all other Entities of the same or a different type. Many times, perhaps even most times, an Entity will be mutable; that is, its state will change over time. Still, an Entity is not of necessity mutable and may be immutable. The main thing that separates an Entity from other modeling tools is its uniqueness—its individuality.
[Vernon, 2016, chapter 5]
The pivotal events mark “important” points in time, where something significant happens in the domain. These pivotal events are a good starting point to identify bounded contexts, as they often mark the boundaries between them.
Early in my career I worked with a electricity utility - here the word “meter” meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty). These subtle polysemes could be smoothed over in conversation but not in the precise world of > computers. Time and time again I see this confusion recur with polysemes like “Customer” and “Product”.
A Value Object, or simply a Value, models an immutable conceptual whole. Within the model the Value is just that, a value. Unlike an Entity, it does not have a unique identity, and equivalence is determined by comparing the attributes encapsulated by the Value type. Furthermore, a Value Object is not a thing but is often used to describe, quantify, or measure an Entity.
[Vernon, 2016, chapter 5]