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.
The terms are just listed in alphabetical order, with links to relevant sources for further reading.
(tbd)
(tbd)
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]
(tbd)
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.
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]
(tbd)
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”.
(tbd)