DOMAIN DRIVEN DESIGN

Domain-Driven Design is an approach to the development of complex software in which we:

  1. Focus on the core domain.
  2. Explore models in a creative collaboration of domain practitioners and software practitioners.
  3. Speak a ubiquitous language within an explicitly bounded context.

= 53 items (filtered by ) /
  • Definitions
    • domain
      A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.
      • model
        A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
        • ubiquitous language
          A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.
          • 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.
            • bounded context
              A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
              • upstream-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.
                • 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.
                  • free
                    A software development context in which the direction, success or failure of development work in other contexts has little effect on delivery.
                    • Building Blocks
                      • Layered Architecture
                        Isolate the domain model and the business logic, eliminate any dependency on infrastructure, user interface, or even application logic that is not business logic.
                        • Entities
                          When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model.
                          • Value Objects
                            When you care only about the attributes and logic of an element of the model, classify it as a value object.
                            • Domain Events
                              Model information about activity in the domain as a series of discrete events.
                              • Services
                                When a significant process or transformation in the domain is not a natural responsibility of an entity or value object, add an operation to the model as a standalone interface declared as a service.
                                • Modules
                                  Choose modules that tell the story of the system and contain a cohesive set of concepts.
                                  • Aggregates
                                    Cluster the entities and value objects into aggregates and define boundaries around each.
                                    • Repositories
                                      For each type of aggregate that needs global access, create a service that can provide the illusion of an in-memory collection of all objects of that aggregate’s root type.
                                      • Factories
                                        Shift the responsibility for creating instances of complex objects and aggregates to a separate object, which may itself have no responsibility in the domain model but is still part of the domain design.
                                        • Supple Design
                                          Have a design that is a pleasure to work with, inviting to change.
                                          • Intention-Revealing Interfaces
                                            Name classes and operations to describe their effect and purpose, without reference to the means by which they do what they promise.
                                            • Side-Effect-Free Functions
                                              Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects.
                                              • Assertions
                                                State post-conditions of operations and invariants of classes and aggregates.
                                                • Closure of Operations
                                                  Where it fits, define an operation whose return type is the same as the type of its argument(s).
                                                  • Declarative Design
                                                    There can be no real guarantees in procedural software. To name just one way of evading assertions, code could have additional side effects that were not specifically excluded.
                                                    • Conceptual Contours
                                                      Decompose design elements (operations, interfaces, classes, and aggregates) into cohesive units, taking into consideration your intuition of the important divisions in the domain.
                                                      • Context Mapping for Strategic Design
                                                        • Context Map
                                                          Identify each model in play on the project and define its bounded context.
                                                          • Partnership
                                                            Where development failure in either of two contexts would result in delivery failure for both, forge a partnership between the teams in charge of the two contexts.
                                                            • Shared Kernel
                                                              Designate with an explicit boundary some subset of the domain model that the teams agree to share. Keep this kernel small.
                                                              • Customer/Supplier Development
                                                                Establish a clear customer/supplier relationship between the two teams, meaning downstream priorities factor into upstream planning.
                                                                • Conformist
                                                                  Eliminate the complexity of translation between bounded contexts by slavishly adhering to the model of the upstream team.
                                                                  • Anticorruption Layer
                                                                    As a downstream client, create an isolating layer to provide your system with functionality of the upstream system in terms of your own domain model.
                                                                    • Open-Host Service
                                                                      Define a protocol that gives access to your subsystem as a set of services.
                                                                      • Published Language
                                                                        Use 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.
                                                                        • Separate Ways
                                                                          Declare a bounded context to have no connection to the others at all, allowing developers to find simple, specialized solutions within this small scope.
                                                                          • Big Ball of Mud
                                                                            Draw a boundary around the entire mess and designate it a big ball of mud.
                                                                            • Distillation for Strategic Design
                                                                              • Core Domain
                                                                                Boil the model down. Define a core domain and provide a means of easily distinguishing it from the mass of supporting model and code.
                                                                                • General Subdomains
                                                                                  Identify cohesive subdomains that are not the motivation for your project.
                                                                                  • Domain Vision Statement
                                                                                    Write a short description (about one page) of the core domain and the value it will bring, the “value proposition.”
                                                                                    • Highlighted Core
                                                                                      Write a very brief document (three to seven sparse pages) that describes the core domain and the primary interactions among core elements.
                                                                                      • Cohesive Mechanisms
                                                                                        Partition a conceptually cohesive mechanism into a separate lightweight framework.
                                                                                        • Segragated Core
                                                                                          Refactor the model to separate the core concepts from supporting players (including ill- defined ones) and strengthen the cohesion of the core while reducing its coupling to other code.
                                                                                          • Abstract Core
                                                                                            Identify the most fundamental differentiating concepts in the model and factor them into distinct classes, abstract classes, or interfaces.
                                                                                            • Large-Scale Structure for Strategic Design
                                                                                              Devise a pattern of rules or roles and relationships that will span the entire system and that allows some understanding of each part’s place in the whole—even without detailed knowledge of the part’s responsibility.
                                                                                              • Evolving Order
                                                                                                Let this conceptual large-scale structure evolve with the application, possibly changing to a completely different type of structure along the way.
                                                                                                • System Metaphor
                                                                                                  When a concrete analogy to the system emerges that captures the imagination of team members and seems to lead thinking in a useful direction, adopt it as a large-scale structure.
                                                                                                  • Responsibility Layers
                                                                                                    Look at the conceptual dependencies in your model and the varying rates and sources of change of different parts of your domain.
                                                                                                    • Knowledge Level
                                                                                                      Create a distinct set of objects that can be used to describe and constrain the structure and behavior of the basic model.
                                                                                                      • Pluggable Component Framework
                                                                                                        Distill an abstract core of interfaces and interactions and create a framework that allows diverse implementations of those interfaces to be freely substituted.
                                                                                                        Pluggable Component FrameworkKnowledge LevelResponsibility LayersSystem MetaphorEvolving OrderLarge-Scale Structure for Strategic DesignAbstract CoreSegragated CoreCohesive MechanismsHighlighted CoreDomain Vision StatementGeneral SubdomainsCore DomainDistillation for Strategic DesignBig Ball of MudSeparate WaysPublished LanguageOpen-Host ServiceAnticorruption LayerConformistCustomer/Supplier DevelopmentShared KernelPartnershipContext MapContext Mapping for Strategic DesignConceptual ContoursDrawing on Established FormalismsDeclarative DesignClosure of OperationsStandalone ClassesAssertionsSide-Effect-Free FunctionsIntention-Revealing InterfacesSupple DesignFactoriesRepositoriesAggregatesModulesServicesDomain EventsValue ObjectsEntitiesLayered ArchitectureBuilding Blocksfreemutually dependentupstream-downstreambounded contextcontextubiquitous languagemodeldomainDefinitionsDomain Driven Design