Domain-driven design: Difference between revisions

Revision as of 07:39, 25 December 2017

Latest revision as of 09:56, 29 July 2025

(221 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Software development process}}

{{refimprove|date=March 2011}}

{{Software development process}}

'''Domain-driven design''' ('''DDD''') is an approach to [[software development]] for complex needs by connecting the [[implementation]] to an evolving model.<ref name="definition">{{Citation | url = http://www.domaindrivendesign.org/ | title = Domain driven design}}.</ref> The premise of ___domain-driven design is the following:

'''Domain-driven design''' ('''DDD''') is a major [[software design]] approach,<ref name="millet2015">{{cite book |last1=Millet |first1=Scott |last2=Tune |first2=Nick |title=Patterns, Principles, and Practices of Domain-Driven Design |date=2015 |publisher=Wrox |___location=Indianapolis |isbn=978-1-118-71470-6}}</ref> focusing on modeling software to match a [[Domain (software engineering)|___domain]] according to input from that ___domain's experts.<ref name="vernon2013">{{cite book |last1=Vernon |first1=Vaughn |title=Implementing Domain-Driven Design |date=2013 |publisher=Addison-Wesley |___location=Upper Sadle River, NJ |isbn=978-0-321-83457-7 |page=3}}</ref> DDD is against the idea of having a single unified model; instead it divides a large system into bounded contexts, each of which have their own model.<ref name="evans2004">{{cite book |last=Evans |first=Eric |url=http://dddcommunity.org/book/evans_2003/ |title=Domain-Driven Design: Tackling Complexity in the Heart of Software |date=August 22, 2003 |publisher=Addison-Wesley |isbn=978-032-112521-7 |___location=Boston |author-link=Eric Evans (technologist) |access-date=2012-08-12}}</ref><ref>{{Cite web |last=martinekuan |title=Using tactical DDD to design microservices - Azure Architecture Center |url=https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd |access-date=2024-09-07 |website=learn.microsoft.com |language=en-us}}</ref>

* placing the project's primary focus on the core [[Domain (software engineering)|___domain]] and ___domain logic;

Under ___domain-driven design, the structure and language of software code (class names, [[class method]]s, [[class variable]]s) should match the business ___domain. For example: if software processes loan applications, it might have classes like "loan application", "customers", and methods such as "accept offer" and "withdraw".

Domain-driven design is predicated on the following goals:

* placing the project's primary focus on the core [[Domain (software engineering)|___domain]] and ___domain logic layer;

* basing complex designs on a model of the ___domain;

* initiating a creative collaboration between technical and [[___domain expert]]s to iteratively refine a conceptual model that addresses particular ___domain problems.

Critics of ___domain-driven design argue that developers must typically implement a great deal of isolation and encapsulation to maintain the model as a pure and helpful construct. While ___domain-driven design provides benefits such as maintainability, Microsoft recommends it only for complex domains where the model provides clear benefits in formulating a common understanding of the ___domain.<ref>Microsoft Application Architecture Guide, 2nd Edition. Retrieved from http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle.</ref>

The term was coined by [[Eric Evans (technologist)|Eric Evans]] in his book of the same titlename published in 2003.<ref name="book.evansevans2004">{{cite book |title=Domain-Driven Design: Tackling Complexity in the Heart of Software |last=Evans |first=Eric |authorlink=Eric Evans (technologist) |year=2004 |publisher=Addison-Wesley |isbn=978-032-112521-7|accessdate=August 12, 2012 |url=http://dddcommunity.org/book/evans_2003/}}.</ref>

==ConceptsOverview==

Domain-driven design articulates a number of high-level concepts and practices.<ref name="evans2004" />

Concepts of the model include:

;Context: The setting in which a word or statement appears that determines its meaning;

;Domain: A sphere of knowledge ([[Ontology (information science)|ontology]]), 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 to connect all the activities of the team with the software.

Of primary importance is a ''___domain'' of the software, the subject area to which the user applies a program. Software's developers build a ''___domain model'': a system of abstractions that describes selected aspects of a ___domain and can be used to solve problems related to that ___domain.

==Strategic ___domain-driven design==

[[File:Maintaining Model Integrity.png|thumb|right|Patterns in strategic ___domain-driven design and the relationships between them]]

Ideally, it would be preferable to have a single, unified model. While this is a noble goal, in reality it typically fragments into multiple models. It is useful to recognize this fact of life and work with it.

These aspects of ___domain-driven design aim to foster a ''common language'' shared by ___domain experts, users, and developers—the ''ubiquitous language''. The ubiquitous language is used in the ___domain model and for describing system requirements.

Strategic Design is a set of principles for maintaining model integrity, distillation of the Domain Model and working with multiple models.

Ubiquitous language is one of the pillars of DDD together with ''strategic design'' and ''tactical design''.

===Bounded context===

Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confusing. It is often unclear in what context a model should not be applied.

In ___domain-driven design, the [[___domain layer]] is one of the [[Common layers in an information system logical architecture|common layers]] in an [[Object-oriented programming|object-oriented]] [[multilayered architecture]].

'''Therefore''':

Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.

===Continuous integrationKinds of models ===

{{Citations needed|date=July 2023}}

When a number of people are working in the same bounded context, there is a strong tendency for the model to fragment. The bigger the team, the bigger the problem, but as few as three or four people can encounter serious problems. Yet breaking down the system into ever-smaller contexts eventually loses a valuable level of integration and coherency.

Domain-driven design recognizes multiple kinds of models. For example, an ''entity'' is an object defined not by its attributes, but its [[Identity (object-oriented programming)|identity]]. As an example, most airlines assign a unique number to seats on every flight: this is the seat's identity. In contrast, a ''[[value object]]'' is an [[Immutable object|immutable]] object that contains attributes but has no conceptual identity. When people exchange business cards, for instance, they only care about the information on the card (its attributes) rather than trying to distinguish between each unique card.

Models can also define ''events'' (something that happened in the past). A ___domain event is an event that ___domain experts care about. Models can be bound together by a root entity to become an ''aggregate''. Objects outside the aggregate are allowed to hold references to the root but not to any other object of the aggregate. The aggregate root checks the consistency of changes in the aggregate. Drivers do not have to individually control each wheel of a car, for instance: they simply drive the car. In this context, a car is an aggregate of several other objects (the engine, the brakes, the headlights, etc.).

'''Therefore''':

Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly. Relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different people’s heads.

===Context mapWorking with models ===

In ___domain-driven design, an object's creation is often separated from the object itself.

An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.

A ''repository'', for instance, is an object with methods for retrieving ___domain objects from a data store (e.g. a database). Similarly, a [[Factory (object-oriented programming)|factory]] is an object with methods for directly creating ___domain objects.

People on other teams won’t be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other.

When part of a program's functionality does not conceptually belong to any object, it is typically expressed as a [[Service (systems architecture)|service]].

'''Therefore''':

Identify each model in play on the project and define its bounded context. This includes the implicit models of non-object-oriented subsystems. Name each bounded context, and make the names part of the ubiquitous language.

Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. Map the existing terrain.

==BuildingEvent blockstypes==

There are different types of [[Event (computing)|events]] in DDD, and opinions on their classification may vary. According to Yan Cui, there are two key categories of events: <ref name=":0">{{Cite book |last=Cui |first=Yan |title=Serverless Architectures on AWS |publisher=Manning |isbn=978-1617295423}}</ref>

In the book ''Domain-Driven Design'',<ref name="book.evans"/> a number of high-level concepts and practices are articulated, such as ''ubiquitous language'' meaning that the ___domain model should form a ''common language'' given by ___domain experts for describing system requirements, that works equally well for the business users or sponsors and for the software developers. The book is very focused on describing the [[___domain layer]] as one of the [[Common layers in an information system logical architecture|common layers]] in an [[object-oriented]] system with a [[multilayered architecture]]. In DDD, there are artifacts to express, create, and retrieve ___domain models:

;[[Entity]]: An object that is not defined by''' its attributes, but rather by a thread of continuity and its [[Identity (object-oriented programming)|identity]].'''

:''Example: Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context. However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object.''

;[[Value object|Value Object]]: An object that contains attributes but has no conceptual identity. They should be treated as [[Immutable object|immutable]].

:''Example: When people exchange business cards, they generally do not distinguish between each unique card; they only are concerned about the information printed on the card. In this context, business cards are value objects.''

;Aggregate: A collection of objects that are bound together by a root entity, otherwise known as an <span id="aggregate_root">[[aggregate root]]</span><!--Preceding span is a link target; disturb only with care-->. The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members.

:''Example: When you drive a car, you do not have to worry about moving the wheels forward, making the engine combust with spark and fuel, etc.; you are simply driving the car. In this context, the car is an aggregate of several other objects and serves as the aggregate root to all of the other systems.''

;Domain Event: A ___domain object that defines an event (something that happens). A ___domain event is an event that ___domain experts care about.

;Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. See also [[Service (systems architecture)]].

;Repository: Methods for retrieving ___domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.

;Factory: Methods for creating ___domain objects should delegate to a specialized [[Factory method pattern|Factory]] object such that alternative implementations may be easily interchanged.

=== Domain Events ===

==Disadvantages==

Domain events signify important occurrences within a specific business ___domain. These events are restricted to a bounded context and are vital for preserving business logic. Typically, ___domain events have lighter [[Payload (computing)|payloads]], containing only the necessary information for processing. This is because event listeners are generally within the same service, where their requirements are more clearly understood.<ref name=":0" />

In order to help maintain the model as a pure and helpful language construct, the team must typically implement a great deal of isolation and encapsulation within the ___domain model. Consequently, a system based on Domain-driven Design can come at a relatively high cost. While Domain-driven Design provides many technical benefits, such as maintainability, Microsoft recommends that it be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the ___domain.<ref>[http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle Microsoft Application Architecture Guide, 2nd Edition]</ref>

=== Integration Events ===

On the other hand, integration events serve to communicate changes across different bounded contexts. They are crucial for ensuring [[data consistency]] throughout the entire system. Integration events tend to have more complex payloads with additional [[Attribute (computing)|attributes]], as the needs of potential listeners can differ significantly. This often leads to a more thorough approach to communication, resulting in overcommunication to ensure that all relevant information is effectively shared.<ref name=":0" />

==Context Mapping patterns==

Context Mapping identifies and defines the boundaries of different domains or subdomains within a larger system. It helps visualize how these contexts interact and relate to each other. Below are some patterns, according to Eric Evans:<ref>{{Cite book |last=Evans |first=Eric |title=Domain-Driven Design Reference: Definitions and Pattern Summaries |isbn=978-1457501197}}</ref>

* Partnership: ''"forge a partnership between the teams in charge of the two contexts. Institute a process for coordinated planning of development and joint management of integration"'', when ''"teams in two contexts will succeed or fail together"''

* 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"'', when ''"two teams are in [a] upstream-downstream relationship"''

* Conformist: ''"Eliminate the complexity of translation [...] choosing conformity enormously simplifies integration"'', when a custom interface for a downstream subsystem isn't likely to happen

* Anticorruption Layer: ''"create an isolating layer to provide your system with functionality of the upstream system in terms of your own ___domain model"''

* Open-host Service: ''"a protocol that gives access to your subsystem as a set of services"'', in case it's necessary to integrate one subsystem with many others, making custom translations between subsystems infeasible

* Published Language: ''"a well-­‐documented shared language that can express the necessary ___domain information as a common medium of communication"'', e.g. [[Electronic data interchange|data interchange standards]] in various industries

* Separate Ways": ''"a bounded context [with] no connection to the others at all, allowing developers to find simple, specialized solutions within this small scope"''

* Big Ball of Mud:<ref>{{Citation | url = http://www.laputan.org/mud/mud.html | title = Big Ball of Mud | first1 = Brian | last1 = Foote | first2 = Joseph | last2 = Yoder | year = 1999 | access-date=2025-05-09}}</ref> ''"a boundary around the entire mess"'' when there's no real boundaries to be found when surveying an existing system

==Relationship to other ideas==

;[[ObjectAlthough ___domain-oriented analysis anddriven design]]: Although,is innot theory,inherently thetied generalto idea[[object-oriented ofanalysis DDD need not be restricted toand design|object-oriented approaches]], in practice, DDDit seeks to exploitexploits the powerful advantages thatof object-orientedsuch techniques make possible. These include entities/aggregate roots as receivers of commands/method invocations and, the encapsulation of state within foremost aggregate roots, and on a higher architectural level, bounded contexts. The reader should be aware that object orientation is not exclusive to OO-only languages, but can be a part of functional programming, also. Applying commands/method invocations to an entity or aggregate root can be seen as an application of a function to a data structure where the result of the function application is an identical data structure with different data and/or version (especially version if optimistic concurrency is used). In dynamic languages such as Ruby or Smalltalk, object instances can be queried on whether they support a method (by name and/or signature), which is similar to how a statically typed language might choose to use an inversion of control container (or a service bus, or a service locator) to support runtime lookup of the objects – services – that support a given protocol/method/command (see CQRS further down).

;[[Model-driven engineering]] (MDE)

;[[Model-driven architecture]] (MDA): While DDD is compatible with MDA, the intent of the two concepts is somewhat different. MDA is concerned more with the means of translating a model into code for different technology platforms than with the practice of defining better ___domain models.

;[[Plain Old Java Object|POJOs]] and [[Plain Old CLR Object|POCOs]]: POJOs and POCOs are technical implementation concepts, specific to [[Java (programming language)|Java]] and the [[.NET framework]] respectively. However, the emergence of the terms POJO and POCO reflect a growing view that, within the context of either of those technical platforms, ___domain objects should be defined purely to implement the business behaviour of the corresponding ___domain concept, rather than be defined by the requirements of a more specific technology framework.

; The [[naked objects]] pattern: Based on the premise that if you have a good enough ___domain model, the user interface can simply be a reflection of this ___domain model; and that if you require the user interface to be a direct reflection of the ___domain model then this will force the design of a better ___domain model.<ref name="book.haywood">{{Citation | last = Haywood | first = D | url = http://www.pragprog.com/titles/dhnako/___domain-driven-design-using-naked-objects | title = Domain-Driven Design using Naked Objects | year = 2009 | publisher = Pragmatic Programmers}}.</ref>

;[[Domain-specific modeling]] (DSM): DSM is DDD applied through the use of [[Domain-specific language]]s.

;[[Domain-specific language]] (DSL): DDD does not specifically require the use of a DSL, though it could be used to help define a DSL and support methods like [[___domain-specific multimodeling]].

;[[Aspect-oriented programming]] (AOP): AOP makes it easy to factor out technical concerns (such as security, transaction management, logging) from a ___domain model, and as such makes it easier to design and implement ___domain models that focus purely on the business logic.

;[[Command Query Responsibility Segregation]] (CQRS): CQRS is an architectural pattern for separation of reads from writes, where the former is a Query and the latter is a Command. Commands mutate state and are hence approximately equivalent to method invocation on aggregate roots/entities. Queries query state but do not mutate it. CQRS is a derivative architectural pattern from the design pattern called Command and Query Separation (CQS) which was coined by Meyer. While CQRS does not require DDD, ___domain-driven design makes the distinction between commands and queries, explicit, around the concept of an aggregate root. The idea is that a given aggregate root has a method that corresponds to a command and a command handler invokes the method on the aggregate root. The aggregate root is responsible for performing the logic of the operation and yielding either a number of events or a failure (exception or execution result enumeration/number) response OR (if Event Sourcing (ES) is not used) just mutating its state for a persister implementation such as an ORM to write to a data store, while the command handler is responsible for pulling in infrastructure concerns related to the saving of the aggregate root's state or events and creating the needed contexts (e.g. transactions).

;[[Event Sourcing]] (ES): An architectural pattern which warrants that your entities (as per [[Eric Evans (technologist)|Eric Evans’]] definition) do not track their internal state by means of direct serialization or O/R mapping, but by means of reading and committing events to an [[event store]]. Where ES is combined with CQRS and DDD, aggregate roots are responsible for thoroughly validating and applying commands (often by means having their instance methods invoked from a Command Handler), and then publishing a single or a set of events which is also the foundation upon which the aggregate roots base their logic for dealing with method invocations. Hence, the input is a command and the output is one or many events which are transactionally (single commit) saved to an event store, and then often published on a message broker for the benefit of those interested (often the views are interested; they are then queried using Query-messages). When modeling your aggregate roots to output events, you can isolate the internal state event further than would be possible when projecting read-data from your entities, as is done in standard n-tier data-passing architectures. One significant benefit from this is that tooling such as axiomatic theorem provers (e.g. Microsoft Contracts or CHESS) are easier to apply, as the aggregate root comprehensively hides its internal state. Events are often persisted based on the version of the aggregate root instance, which yields a ___domain model that synchronizes in distributed systems around the concept of optimistic concurrency.

As a result, ___domain-driven design is often associated with [[Plain Old Java Objects]] and [[Plain Old CLR Object|Plain Old CLR Objects]], which are technical implementation details, specific to [[Java (programming language)|Java]] and the [[.NET Framework]] respectively. These terms reflect a growing view that ___domain objects should be defined purely by the business behavior of the ___domain, rather than by a more specific technology framework.

==Tools==

Similarly, the [[naked objects]] pattern holds that the user interface can simply be a reflection of a good enough ___domain model. Requiring the user interface to be a direct reflection of the ___domain model will force the design of a better ___domain model.<ref name="book.haywood">{{Citation|last=Haywood|first=Dan|title=Domain-Driven Design using Naked Objects|url=http://www.pragprog.com/titles/dhnako/___domain-driven-design-using-naked-objects|year=2009|publisher=Pragmatic Programmers}}.</ref>

Practicing DDD does not depend upon the use of any particular software tool or framework. Nonetheless, there is a growing number of open-source tools and frameworks that provide support to the specific patterns advocated in Evans' book or the general approach of DDD. Among these are:

* [[Actifsource]] is a plug-in for [[Eclipse (software)|Eclipse]] which enables software development combining DDD with [[model-driven engineering]] and [[Automatic programming|code generation]].

Domain-driven design has influenced other approaches to software development.

* Apache Isis is a [[Java SE|Java]] framework for developing ___domain-driven and [[Representational state transfer|RESTful]] applications using the [[Naked objects|Naked Objects]] pattern.

*[[ECO (Domain Driven Design)]]: Framework with database, class, code and state machine generation from UML diagrams by CapableObjects.

[[Domain-specific modeling]], for instance, is ___domain-driven design applied with [[___domain-specific language]]s. Domain-driven design does not specifically require the use of a ___domain-specific language, though it could be used to help define a ___domain-specific language and support [[___domain-specific multimodeling]].

*[[OpenMDX]]: Open source, Java based, MDA Framework supporting [[Java SE]], [[Java EE]], and [[.NET Framework|.NET]]. OpenMDX differs from typical MDA frameworks in that ''"use models to directly drive the runtime behavior of operational systems"''.

*[[OpenXava]]: Generates an [[AJAX]] application from [[Java Persistence API|JPA]] entities. You only need to write the ___domain classes to obtain a ready to use application.

In turn, [[aspect-oriented programming]] makes it easy to factor out technical concerns (such as security, transaction management, logging) from a ___domain model, letting them focus purely on the business logic.

* [[Restful Objects]] is a standard for a Restful API onto a ___domain object model (where the ___domain objects may represent entities, view models, or services). Two open source frameworks (one for Java, one for .NET) can create a Restful Objects API from a ___domain model automatically, using reflection.

* [[CubicWeb]] is an open source semantic web framework entirely driven by a data model. High-level directives allow to refine the data model iteratively, release after release. Defining the data model is enough to get a functioning web application. Further work is required to define how the data is displayed when the default views are not sufficient.

=== Model-driven engineering and architecture ===

* ENode: is a C# framework which support to develop DDD+CQRS+Event Sourcing architecture style applications.

While ___domain-driven design is compatible with [[model-driven engineering]] and [[model-driven architecture]],<ref>[https://modeling-languages.com/clarifying-concepts-mbe-vs-mde-vs-mdd-vs-mda/ MDE can be regarded as a superset of MDA]</ref> the intent behind the two concepts is different. Model-driven architecture is more concerned with translating a model into code for different technology platforms than defining better ___domain models.

However, the techniques provided by model-driven engineering (to model domains, to create ___domain-specific languages to facilitate the communication between ___domain experts and developers,...) facilitate ___domain-driven design in practice and help practitioners get more out of their models. Thanks to model-driven engineering's model transformation and code generation techniques, the ___domain model can be used to generate the actual software system that will manage it.<ref>{{Cite web|last=Cabot|first=Jordi|date=2017-09-11|title=Comparing Domain-Driven Design with Model-Driven Engineering|url=https://modeling-languages.com/comparing-___domain-driven-design-model-driven-engineering/|access-date=2021-08-05|website=Modeling Languages|language=en-US}}</ref>

=== Command Query Responsibility Segregation ===

[[Command Query Responsibility Segregation]] (CQRS) is an architectural pattern for separating reading data (a 'query') from writing to data (a 'command'). CQRS derives from Command and Query Separation (CQS), coined by [[Bertrand Meyer]].

Commands mutate state and are approximately equivalent to method invocation on aggregate roots or entities. Queries read state but do not mutate it.

While CQRS does not require ___domain-driven design, it makes the distinction between commands and queries explicit with the concept of an aggregate root. The idea is that a given aggregate root has a method that corresponds to a command and a command handler invokes the method on the aggregate root.

The aggregate root is responsible for performing the logic of the operation and either yielding a failure response or just mutating its own state that can be written to a data store. The command handler pulls in infrastructure concerns related to saving the aggregate root's state and creating needed contexts (e.g., transactions).

=== Event storming ===

[[Event storming]] is a collaborative, workshop-based modeling technique which can be used as a precursor in the context of Domain-Driven Design (DDD) to identify and understand ___domain events. This interactive discovery process involves stakeholders, ___domain experts, and developers working together to visualize the flow of ___domain events, their causes, and their effects, fostering a shared understanding of the ___domain. The technique often uses color-coded sticky notes to represent different elements, such as ___domain events, aggregates, and external systems, facilitating a clear and structured exploration of the ___domain. Event storming can aid in discovering subdomains, bounded contexts, and aggregate boundaries, which are key constructs in DDD. By focusing on 'what happens' in the ___domain, the technique can help uncover business processes, dependencies, and interactions, providing a foundation for implementing DDD principles and aligning system design with business goals. <ref>{{Cite book |title=Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy |isbn=978-1098100131}}</ref><ref>{{Cite book |title=Open Agile ArchitectureTM - A Standard of The Open Group |isbn=9789401807265}}</ref>

=== Event sourcing ===

Event sourcing is an architectural pattern in which entities track their internal state not by means of direct serialization or object-relational mapping, but by reading and committing events to an [[event store]].

When event sourcing is combined with [[CQRS]] and ___domain-driven design, aggregate roots are responsible for validating and applying commands (often by having their instance methods invoked from a Command Handler), and then publishing events. This is also the foundation upon which the aggregate roots base their logic for dealing with method invocations. Hence, the input is a command and the output is one or many events which are saved to an event store, and then often published on a message broker for those interested (such as an [[Model–view–controller|application's view]]).

Modeling aggregate roots to output events can isolate internal state even further than when projecting read-data from entities, as in standard ''n''-tier data-passing architectures. One significant benefit is that axiomatic theorem provers (e.g. Microsoft Contracts and CHESS<ref>[https://www.microsoft.com/en-us/research/project/chess-find-and-reproduce-heisenbugs-in-concurrent-programs/ a MS bug finding tool]</ref>) are easier to apply, as the aggregate root comprehensively hides its internal state. Events are often persisted based on the version of the aggregate root instance, which yields a ___domain model that synchronizes in distributed systems through [[Optimistic concurrency control|optimistic concurrency]].

== Mapping Bounded Contexts to Microservices ==

A bounded context, a fundamental concept in Domain-Driven Design (DDD), defines a specific area within which a ___domain model is consistent and valid, ensuring clarity and separation of concerns. <ref>{{Cite book |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |year=2020 |isbn=978-1492043454}}</ref> In [[microservices]] architecture, a bounded context often maps to a microservice, but this relationship can vary depending on the design approach. A one-to-one relationship, where each bounded context is implemented as a single microservice, is typically ideal as it maintains clear boundaries, reduces coupling, and enables independent deployment and scaling. However, other mappings may also be appropriate: a one-to-many relationship can arise when a bounded context is divided into multiple microservices to address varying scalability or other operational needs, while a many-to-one relationship may consolidate multiple bounded contexts into a single microservice for simplicity or to minimize operational overhead. The choice of relationship should balance the principles of DDD with the system's business goals, technical constraints, and operational requirements. <ref>{{Cite book |title=Building Microservices by Sam Newman |isbn=978-1492034025}}</ref>

== Notable tools ==

Although ___domain-driven design does not depend on any particular tool or framework, notable examples include:

* [[Actifsource]], a plug-in for [[Eclipse (software)|Eclipse]] which enables software development combining DDD with [[model-driven engineering]] and [[Automatic programming|code generation]].

* Context Mapper, a [[Domain-specific language]] and tools for strategic and tactic DDD.<ref>Stefan Kapferer and Olaf Zimmermann: Domain-driven Service Design - Context Modeling, Model Refactoring and Contract Generation, 14th Symposium and Summer School On Service-Oriented Computing (SommerSoC 2020)[https://contextmapper.org/media/SummerSoC-2020_Domain-driven-Service-Design_Authors-Copy.pdf]</ref>

* [[CubicWeb]], an open source semantic web framework entirely driven by a data model. High-level directives allow to refine the data model iteratively, release after release. Defining the data model is enough to get a functioning web application. Further work is required to define how the data is displayed when the default views are not sufficient.

*[[OpenMDX]], an open-source, Java-based, MDA Framework supporting [[Java SE]], [[Java EE]], and [[.NET Framework|.NET]]. OpenMDX differs from typical MDA frameworks in that ''"use models to directly drive the runtime behavior of operational systems"''.

* [[Restful Objects]], a standard for mapping a Restful API onto a ___domain object model (where the ___domain objects may represent entities, view models, or services). Two open source frameworks (one for Java, one for .NET) can create a Restful Objects API from a ___domain model automatically, using reflection.

==See also==

* [[Data mesh]], a ___domain-oriented data architecture

* [[Domain of a function]]

* [[Event Stormingstorming]]

* [[Knowledge representation]]

* [[Ontology (information science)]]

Line 90 ⟶ 117:

* [[Semantic networks]]

* [[Semantics]]

* [[C4 model]]

* [[Strongly typed identifier]]

* [[Integrated design]]

* [[Systems science]]

==References==

{{reflistReflist}}

==External links==

* {{Citation | url =https://domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf | title = Domain Driven Design, Definitions and Pattern Summaries | publisher = Eric Evans, 2015}}

* [https://www.codeproject.com/Articles/1055514/Aggregate-Root-Pattern-in-Csharp Implementing Aggregate root in C# language]

* [https://github.com/ddd-crew DDD Crew on GitHub]: Bounded Context Canvas, Aggregate Canvas, Modeling Process and more repositories

* {{Citation | url = http://www.methodsandtools.com/archive/archive.php?id=97 | title = An Introduction to Domain Driven Design | publisher = Methods & tools}}

* [https://www.codeproject.com/Articles/1055514/Aggregate-Root-Pattern-in-Csharp Implementing Aggregate root in C# language]

* {{Citation | url = http://www.infoq.com/articles/haywood-ddd-no | first = Dan | last = Haywood | type = interview | publisher = InfoQ | title = Domain Driven Design using Naked Objects}}

* [https://contextmapper.org/ Context Mapper: A Modeling Framework for Strategic Domain-driven Design (Tool, Tutorials, DDD Modeling Examples)]

* {{Citation | url = https://medium.com/@wrong.about/ddd-strategic-patterns-how-to-define-bounded-contexts-2dc70927976e | title = How To Define Bounded Contexts}}

* [https://socadk.github.io/design-practice-repository/activities/DPR-StrategicDDD.html Strategic DDC Activity in Design Practice Repository (DPR)] and [https://socadk.github.io/design-practice-repository/activities/DPR-TacticDDD.html Tactic DDC Activity in Design Practice Repository (DPR)]

[[Category:Software architecture]]