Concept Map of the Domain Driven Design Patterns
May 17, 2025 · View on GitHub
Diagram
Description
Shows the concepts of Domain Driven Design and their relationships.
Concepts
| Concept | Description |
|---|---|
| Abstract Core | The most fundamental differentiating concepts in the model, factored into distinct classes, abstract classes, or interfaces. |
| Aggregates | Aggregates are collections of entities and value objects with their associations and form a transactional unit. Aggregates are referenced as a whole by an aggregate root entity, parts of the aggregate must not be referenced from outside. The aggregate root is responsible for the enforcement of the busines rules and invariants of the aggregate. |
| Anti-Corruption Layer | The anti-corruption layer is an architectural layer to separate the domain model from outside models. It enables the domain model to access the data of the outside model as expected by the domain model. In a clean architecture, an adapter is the place to implement the anti- corruption layer by mapping the outside model to the domain model. |
| Assertions | state post-conditions of operations and invariants of classes and aggregates |
| Big Ball of Mud | A Big Ball of Mud is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. |
| Bounded Context | A descrition of a boundary (typically a subsystem or the work of a particular team) within which a particular model is defined and applicable. |
| Building Blocks | Part II: The Building Blocks of a Model-Driven Design |
| Clean Architecture | |
| Closure of Operations | define an operation whose return type is the same as the type of its argument(s) |
| Cohesive Mechanisms | |
| Conceptual Contours | decompose design elements into cohesive units |
| Conformist | |
| Context | The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context. |
| Context Map | The context map provides an overview for all models and their boundaries and interfaces. |
| Context Mapping | Part IV: Context Mapping for Strategic Design |
| Continuous Integration | A process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly. |
| Core Domain | The most valuable part of the domain model. |
| Customer/Supplier | A clear relationship between two teams, where the downstream team is the customer of the upstream team. |
| Declarative Design | |
| Distillation | Part V: Distillation for Strategic Design |
| Domain | A sphere of knowledge, influence or activity. The subject area to which a user applies a program is the domain of the software. |
| Domain Driven Design | An approach to the development of complex software in which we focus on the core domain, explore models in a creative collaboration of domain practitioners and software practitioners, and speak a ubiquitous language within an explicitly bounded context. |
| Domain Events | A domain object to propagate relevant domain activities in a distributed system. |
| Domain Vision Statement | A short description of the core domain and the value it will bring. |
| Entities | Objects in the domain model which are defined by their identity rather than by their state. For example a Person is normally modelled as an entity. It represents the same person even when the attributes change. It is also a different person, even if it has the same state as another person. |
| Established Formalisms | |
| Evolving Order | A conceptual large-scale structure that evolves with the application, possibly changing to a completely different type of structure along the way. |
| Factories | A domain object for the creation of complex domain objects which enforce the invariants of these objects on creation. |
| Generic Subdomains | A cohesive subdomain that is not the motivation for the project and does not capoure specialized knowledge. |
| Hands On Modellers | Developers must be involved with the model and have contact with domain experts. |
| Highlighted Core | Describes the core elements of the domain and their interactions. |
| Intention-Revealing Interfaces | name classes and operations to describe their effect and purpose |
| Knowledge-level | A distinct set of objects that can be used to describe and constrain the structure and behavior of the basic model. |
| Large Scale Structure | |
| Large-scale Structure | Part VI: Large-scale Structure for Strategic Design |
| Layered Architecture | Isolates the expression of the domain model and the business logic, and eliminates any dependency on infrastructure, user interface, or application logic that is not business logic. |
| Model | A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. |
| Model Driven Design | |
| Modules | |
| Open Host Service | An open protocol that gives access to your subsystem as a set of services. |
| Partnership | A partnership between the teams in charge of the two contexts, when the teams will succeed or fail together. |
| Pluggable Component Framework | A framework that allows diverse implementations of those interfaces to be freely substituted. |
| Published Language | A well-documented shared language that can express the necessary domain information as a common medium of communication, translating as necessary into and out of that language. |
| Putting the Model to Work | Part I: Putting the Model to Work |
| Repositories | Query access to aggregates expressed in the ubiquitous language |
| Responsibility Layers | |
| Segregated Core | |
| Separate Ways | A bounded context with no connection to the others at all, allowing developers to find simple, specialized solutions within this small scope. |
| Services | contains functionality which is not the responsiblity of an entity or value object |
| Shared Kernel | |
| Side-Effect-Free Functions | implement logic with functions that return results without observable side effects |
| Standalone Classes | when possible create classes that are self-contained and can be understood alone |
| Supple Design | Part III: Supple Design |
| System Metaphor | |
| Ubiquitous Language | A language around the domain model used by all team members within a bounded context to connect all the activities of the team with the software. |
| Value Objects | An object in the domain model, which has no conceptional identity but are identified by their state. Value objects should be modelled as immutable. |
| free | A software development context in which the direction, success or failure of development work in other contexts has little effect on delivery. |
| mutually dependent | A situation in which two software development projects in separate contexts must both be delivered in order for either to be considered a success. |
| upsteam-downstream | A relationship between two groups in which the “upstream” group’s actions affect project success of the “downstream” group, but the actions of the downstream do not significantly affect projects upstream. |
Other Relationships
Navigation
(generated by Overarch with template docs/view.md.cmb)