The Ultimate Glossary of Key Concepts in Domain-Driven Design (DDD) and Event Storming
Introduction
In the world of software development, particularly in complex domains, Domain-Driven Design (DDD) and Event Storming are essential methodologies for creating highly maintainable and scalable systems. This glossary defines all the key concepts you need to understand these powerful techniques, making it easier for you to apply them in your projects.
Understanding these key concepts is crucial for anyone involved in complex software projects. Whether you're a domain expert, developer, architect, or business analyst, mastering these terms will enhance your ability to create effective, maintainable, and scalable systems.
A successful adoption of DDD and Event Storming will result in better communication, more efficient workflows, and ultimately, more successful projects.
Domain-Driven Design (DDD) Concepts
Domain Model
A domain model is an abstract representation of the domain, capturing the key entities, their relationships, and the rules governing them. The domain model is the foundation for the software architecture.
Domain
The domain is the primary business problem area that your software aims to solve. It includes the specific context, rules, and knowledge required to create meaningful solutions for the business.
Subdomain
Subdomains are specific parts of the overall domain, each representing a particular business function or process. Subdomains are categorized into Core, Supporting, and Generic Subdomains based on their importance to the business.
Core Domain
The core domain is the most critical subdomain within the larger domain, directly reflecting the primary value proposition of the business. It is where you should invest most of your efforts.
Bounded Context
A bounded context defines a boundary within which a particular model is applicable. It ensures that within a specific context, terms and concepts have a clear, consistent meaning, reducing ambiguity and misunderstanding.
Ubiquitous Language
Ubiquitous Language is a shared language developed by the team, including developers, domain experts, and stakeholders. It ensures that everyone has a common understanding of key terms and concepts within the domain.
Entity
An entity is an object with a unique identity that runs through multiple states during its lifecycle. In DDD, entities are often the central objects being manipulated and changed. Examples include Order ID and Customer ID.
Value Object
A value object is an immutable type that is defined by its attributes rather than a unique identity. Examples include measurements, dates, or monetary amounts.
Aggregate
An aggregate is a cluster of domain objects that are treated as a single unit for data changes. The aggregate's root entity, known as the Aggregate Root, ensures the integrity of changes across the aggregate. They help in organizing the domain model and understanding the boundaries within which certain rules apply.
Aggregate Root
The aggregate root is the main entity in an aggregate, which controls access to other entities in the aggregate. It ensures that the aggregate's state is consistent.
Repository
A repository is a mechanism for encapsulating storage, retrieval, and search behavior. It allows for accessing domain entities and aggregates as if they were in memory.
Factory
A factory is responsible for creating complex objects or aggregates, ensuring that the objects are in a valid state upon creation.
Service
A service is an operation or a set of operations that are not naturally part of an entity or value object. Services can be domain services (related to the business logic) or application services (related to application logic).
Domain Event
A domain event is a significant occurrence in the domain that the business cares about. It is a fact that something occurred and is used to trigger subsequent processes or actions.
Event Sourcing
Event sourcing is a technique where state changes are stored as a sequence of events, rather than just the current state. This allows you to reconstruct past states by replaying the events.
Command
A command represents an intent to perform an action, which can change the state of an aggregate and causes a domain event to occur. It is part of the Command-Query Responsibility Segregation (CQRS) pattern.
Command-Query Responsibility Segregation (CQRS)
CQRS is a design pattern where the responsibility for handling commands (which change state) is separated from the responsibility of handling queries (which read state). This separation allows for optimized and scalable architectures.
Anti-Corruption Layer
The Anti-Corruption Layer (ACL) acts as a translator or adapter between two bounded contexts, ensuring that one context is not negatively impacted by the inconsistencies or complexities of another.
Context Map
A context map is a visual representation of the relationships and interactions between different bounded contexts in a system. It helps to identify dependencies and integration points.
Event Storming Concepts
Big Picture Event Storming
Big Picture Event Storming is a high-level exploration of the entire business domain, identifying key domain events, actors and systems. It helps to create a shared understanding of the overall system.
Process Modeling Event Storming
Process Level Event Storming dives deeper into a specific business process, mapping out detailed domain events, commands, policies, read models and interactions. It is used to model the finer details of how a process operates.
Software Design Event Storming
Design Level Event Storming focuses on technical implementation, defining how the domain model will be realized in the code. It involves decisions on aggregates, repositories and services.
Domain Event
See explanation above.
Command
See explanation above.
Read Model
A Read Model represents the way data is organized and optimized for reading or querying purposes, often used in CQRS patterns. Unlike the write model, which handles commands and state changes, the read model is designed to quickly retrieve information that is relevant to the user or the system so that the user can take a given decision. Identifying read models during Event Storming helps clarify how the system will present data to different stakeholders.
Actor
An actor is any person, system, or external entity that interacts with the system and triggers commands. Actors are identified to understand who initiates actions within the domain.
System
A system refers to the broader technological and operational environment within which the domain operates. It encompasses all software, hardware, and external services that interact with or support the domain. In Event Storming sessions, recognizing the system helps to understand the boundaries, dependencies, and integrations that need to be managed during implementation. A system is treated like a black box.
Aggregate
See explanation above.
Policy
A policy represents a business rule or logic that dictates how events or commands should be handled. Policies are essential for understanding complex business logic and its impact on the domain.
Hot Spot
A hot spot is an area of uncertainty or potential problem in the domain that requires further exploration. Hot spots are flagged during Event Storming sessions to highlight areas that need more attention.
Opportunity
An opportunity in Event Storming is identified as a potential area for improvement, innovation, or added value within the domain. It could be an unmet business need, a process that could be optimized, or a new feature that could enhance the system. Highlighting opportunities during Event Storming helps teams focus on areas where they can make the most impactful changes.
Key Events
Key events are the most critical domain events that drive significant business processes. In Event Storming, identifying key events helps prioritize what parts of the domain to focus on.
Event Stream
An event stream is the chronological sequence of domain events that have occurred within a system. In Event Storming, event streams are mapped out to understand the flow and dependencies between events.
UI (User Interface)
The User Interface (UI) refers to the points of interaction between users and the system. Understanding the UI components is crucial as it influences how users will interact with the domain model. During Event Storming, mapping out the UI helps to ensure that user actions are clearly linked to domain events, commands, and read models, providing a cohesive user experience.