Domain-driven design

from Wikipedia, the free encyclopedia

Domain-driven design ( DDD ) is an approach to modeling complex software . The modeling software is thereby materially from those to be implemented Fachlichkeiten the application domain affected. The term "domain-driven design" was coined in 2003 by Eric Evans in his book of the same name.

description

Domain-driven design is not just a technique or a method. Rather, it is a way of thinking and prioritizing to increase the productivity of software projects in the environment of complex technical contexts. Domain-driven design is based on the following two assumptions:

  • The focus of the software design is on the technicality and the technical logic.
  • The design of complex technical relationships should be based on a model of the application domain, the domain model.

Domain-driven design is not tied to any specific software development process , but is based on agile software development . In particular, it requires iterative software development and close cooperation between developers and subject matter experts.

Layer architecture

The purpose of all software is to support the tasks of a specific application domain. In order to be able to do this successfully, the software must harmoniously match the subject matter of the application domain for which it is intended. Domain-driven design makes this possible by the software modeling basic concepts and elements of the application domain and their relationships.

The architecture is characterized by the existence of an explicit business logic layer. This layer should decouple the domain classes from other functions of the system and make them as easily recognizable as possible. Various architectural styles can be used to embed the business logic layer. These include the layered architecture and the hexagonal architecture.

In the domain-driven design, the classes of the domain model contain both the data and the entire functionality of the subject matter to be implemented, i.e. the entire subject logic. The anemic domain model is therefore considered an antipattern , since it describes a domain model without any technical logic.

Domain-driven design contrasts with the less complex Smart UI development pattern . When using Smart UI, the application logic is integrated directly into the user interface. This means that no dedicated layer for application logic can be created that can be reused by different components.

Ubiquitous language

Domain-driven design is based on a number of concepts that should be taken into account in modeling - but also in other software development activities . The main focus here is on the introduction of a ubiquitous (commonly used, ubiquitous, ubiquitous ) language, which should be used in all areas of software development. A language for the description of the business, the elements of the domain model, the classes and methods etc. It is defined as:

"A language structured around the domain model and used by all team members to connect all the activities of the team with the software."

"A language that is structured around the application domain and used by all team members to link all team activities with the software."

- Eric Evans : Presentation documents from his talk on November 6, 2007 at JAOO

Domain-driven design is itself independent of programming languages, tools and frameworks. Nevertheless, there are a number of tools and frameworks that offer support for the implementation of specific DDD patterns or support the approach of DDD.

Components of the domain model

Domain model

Domain-driven design distinguishes between the following components of the domain model:

Entities ( Entities , reference objects )
Objects of the model which are not defined by their properties but by their identity. For example, a person is usually depicted as an entity. A person remains the same when their characteristics change; and they are different from another person, even if they have the same characteristics. Entities are often modeled with the help of unique identifiers .
Value objects ( valueObjects )
Objects of the model that do not have or need no conceptual identity and are thus defined solely by their properties. Valuable objects are usually as immutable objects ( immutable objects ) models, so they are reusable (see. Flyweight ) and distributable.
Aggregate ( aggregates )
Aggregates are combinations of entities and value objects and their associations with one another to form a common transactional unit. Aggregates define exactly one entity as the only access to the entire aggregate. All other entities and value objects may not be statically referenced from outside. This guarantees that all invariants of the aggregate and the individual components of the aggregate can be ensured.
Associations ( associations )
As defined in UML , associations are relationships between two or more objects of the domain model. Here, not only static relationships defined by references are considered, but also dynamic relationships that arise, for example, only through the processing of SQL queries.
Service objects ( services )
In domain-driven design, functionalities, which represent an important concept of technicality and conceptually belong to several objects of the domain model, are modeled as independent service objects. Service objects are usually stateless and therefore reusable classes without associations, with methods that correspond to the functionalities offered. These methods receive the value objects and entities that are necessary for processing the functionality.
Technical events ( domain events )
Business events are objects which describe complex, under certain circumstances dynamically changing, actions of the domain model that cause one or more actions or changes in the business objects. Business events also enable the modeling of distributed systems. The individual subsystems communicate exclusively via technical events, so they are strongly decoupled and the entire system is more maintainable and scalable .
Modules ( modules , packages )
Modules divide the domain model into functional (non-technical) components. They are characterized by strong internal cohesion and low coupling between the modules.

Domain-driven design also knows two other components of the domain model - factories and repositories . Although these do not implement business functionality themselves, they are still part of the domain model, as they provide important functionality for the life cycle of the business objects.

Factories ( factories )
Factories serve to outsource the production of technical objects to special factory objects. This is useful if either the generation is complex (and, for example, requires associations that the technical object itself no longer needs) or the specific creation of the technical objects should be able to be exchanged at runtime. Factories are usually implemented through generating design patterns such as abstract factory , factory method or builder .
Repositories
Repositories abstract the persistence and search of specialist objects. The technical infrastructure and all access mechanisms to this are separated from the business logic layer by means of repositories . A repository class is provided for all technical objects that are loaded via the infrastructure layer, which encapsulates the loading and search technologies used from the outside. The repositories themselves are part of the domain model and thus part of the business logic layer. They are the only ones to access the objects of the infrastructure layer, which are mostly implemented using the design pattern Data Access Objects , Query Objects or Metadata Mapping Layers .

The names of the classes of the business logic layer corresponding to these patterns are parts of the ubiquitous language and should be named accordingly. A change in the name of a technical object through refactoring thus corresponds to a change in the technical nature of the application.

More techniques

Domain-driven design describes and recommends a number of other techniques and approaches for implementing the domain model:

Architectural techniques

Evolving structure ( evolving order )
assumes that large structures in the domain model ideally only emerge over time or develop over time. Large structures should be implemented as simply as possible and with as few exceptions as possible.
System metaphor ( system metaphor )
is a concept from Extreme Programming , which facilitates communication between all those involved by describing the system using a metaphor, an everyday story that is similar in content and understandable for all parties. This should fit as well as possible and be used to strengthen the ubiquitous language.
Responsibility layers ( responsibility layers )
is the division of the domain model into layers according to responsibilities. Domain-driven design suggests the following layers: decision-making layer, rule layer, commitments, work processes, potential.
Level knowledge ( knowledge level )
describes the explicit knowledge of the domain model. It is necessary in situations where the dependencies and roles between the entities vary depending on the situation. The knowledge level should contain these dependencies and roles in an externally adaptable way so that the domain model can remain specific and without unnecessary dependencies.
Extension frameworks ( pluggable component framework )
is the idea of ​​connecting different systems to one another via a component framework.

Design techniques

Intentions descriptive interfaces ( intention-revealing interfaces )
denote interfaces of classes and components, which enable developers to use them without having to study their source code. This ensures that these classes and components are used and maintained according to their intentions.
Side-effect-free functions ( side-effect-free functions )
are methods that have no influence on the status of a module. These are easier to test and should therefore be preferred. They should therefore contain the majority of the application logic. Methods that change the state - so-called command methods - should be separated from them, kept as simple as possible and not return any classes of the domain model.
Assertions
serve in domain-driven design to make side effects of called methods visible without having to study their source code. This approach - which is close to design by contract - means that developers can understand the effects of the methods used, and thus data encapsulation can only be used correctly.
Independent classes ( stand alone classes )
are classes that have no explicit or implicit dependencies on other classes. They are easier to understand and should therefore be aimed for by eliminating all unnecessary dependencies.
Conceptual contours ( conceptual contours )
describes the concepts that underlie the structure of a design. These should be adapted to the stable aspects of the subject matter through successive refactoring. This increases the likelihood that future changes can be implemented more easily with the existing design.
Functional degrees ( closure of operations )
in domain-driven design are methods whose return type is the same as that of their arguments or the attributes used in the method. Although these methods expand the capabilities of a class, they do not introduce dependencies on other concepts. They are therefore preferable to methods whose return other types introduce.
Anti corruption layer ( anticorruption layer )
is an architectural layer that separates the domain model from other models. Even part of the domain model, the anti-corruption layer enables the third-party model to be accessed as required by one's own domain model. The own concepts and language elements are translated to those of the foreign model, the own domain model is not influenced by the foreign model. This is mostly implemented with the facade , adapter and transfer object design patterns.

These and other common design techniques of object orientation lead to a declarative style ( declarative style ) of the design. This not only makes the code shorter, easier to understand and easier to test, but also makes it possible to work out the core technicality and thus concentrate on the relevant technical functions of a software.

Procedures

In addition, domain-driven design defines a series of procedures which serve to guarantee the integrity of the models. This is particularly necessary when several teams under different management and coordination on different subject areas are to work together in a large project.

The graphic shows the dependencies between these and other elements of domain-driven design.

Procedures
Vision of professionalism ( domain vision statement )
is a brief description of the vision behind the core technicality and the associated goals. It specifies the development direction of the domain model and serves as a link between the project vision / system metaphor and the details of the core business and the code.
Context Overview ( context map )
provides a complete overview of all models, their limits and interfaces. As a result, the contexts do not grow into areas of other contexts, and communication between the contexts takes place via well-defined interfaces.
Context boundaries ( bounded context )
describe the boundaries of each context in a variety of ways, such as team assignment, intended use, underlying database schemes. This makes it clear where a context loses its validity and another context potentially takes its place.
Kernfachlichkeit ( core domain )
is the most valuable part of the domain model, the part that brings the most user benefits. The other parts of the domain model primarily serve to support the core business and to enrich it with less important functions. When modeling, special attention should be paid to the core technicality, and it should be implemented by the best developers.
Split Core ( shared kernel )
is part of the subject matter that is shared between different project parts. This is useful if the different project parts are only loosely connected and the project is too big to be implemented in a team. The shared core is developed jointly by all project teams that use it. This requires a lot of coordination and integration effort.
Customer-supplier ( customer-supplier )
is the metaphor for the relationship between project teams in which one team implements a technicality on which the other team builds. This ensures that the dependent team is well supported by the implementing team, as their requirements are implemented with the same priority as the actual requirements for the supplier team.
Separated core ( segregated core )
refers to the idea of ​​moving the core subject matter, even if it is closely linked to supporting model elements, into a separate module and reducing the coupling with other modules. This protects the core technicality from high complexity and increases maintainability.
Generic sub-Fachlichkeiten ( generic subdomains )
describes the idea of ​​storing those parts of the domain model that do not belong to the core subject area in the form of models that are as generic as possible in separate modules. Since they do not represent the core business and are generic, they could be developed outsourced or replaced by standard software.
Continuous integration ( continuous integration )
In domain-driven design, it is used to continuously integrate all changes to a domain model with one another and to be able to automatically test them against existing specialist knowledge.

Comparison with other approaches and techniques

Object-oriented analysis and design
Although DDD is theoretically not limited to object-oriented concepts, in practice DDD is mainly used for object-oriented analysis and design. Many of the concepts of DDD are based on paradigms of object-oriented software development. DDD can thus be seen as a methodology for object-oriented analysis and design.
Model -driven software development and model-driven architecture (MDA)
DDD is compatible with model-driven software development, but has different intentions. Model-driven software development is more concerned with the techniques of how models can be implemented in different software platforms, while DDD is mainly concerned with how better domain models can be achieved. DDD relies heavily on a continuously evolving model, which is improved through ongoing refactoring , and whose implementation on software platforms can be supported by model-driven software development.
Plain Old Java Objects (POJOs) and Plain Old CLR Objects (POCOs)
POJOs and POCOs are technical concepts from Java and .NET . However, they are based on the view also propagated in DDD that technical objects should only implement requirements of the technicalities of the domain model and not technology-specific requirements.
Naked Objects
Naked Objects is an architecture pattern which, like DDD, assumes that the entire technical logic is to be mapped in technical objects. In addition, the Naked Objects architecture pattern propagates that the user interface is a direct representation of the technical objects and should therefore be generated completely from the technical objects - a requirement that DDD does not make.
Object-oriented persistence mechanisms
Object-oriented persistence mechanisms such as object-relational mapping or object databases deal with the replacement of the data access layer under the technical objects. They are therefore a synergetic addition to domain-driven design, as the architecture is even more centered on the specialist objects.
Data Context Interaction (DCI)
Data Context Interaction is an architecture pattern that can supplement the components of the domain model of the domain-driven design (entities, value objects, aggregates, service objects and business events) or can be supplemented by them. The data objects of DCI can be refined by the entities, value objects and aggregates of DDD, context objects in turn can be represented by service objects and business events. The roles of the interactions of DCI, however, in turn expand the components of the domain-driven design. Both technologies can therefore be viewed as compatible and complementary to one another.
Domain-specific language (DSL)
A domain-specific language (DSL) is a formal language that is specifically designed and implemented for a specific problem area (the problem domain ). DDD is not itself and does not require DSL in order to function.
Aspect-oriented programming (AOP)
AOP is a technology that enables DDD to separate certain, otherwise usually deeply interwoven technical aspects (such as logging , security, transaction management ) from the domain model. This makes it easy to meet DDD's claim of complete separation of the domain model from the rest of the application.
Tool and material approach (WAM)
WAM is a method of software development that is oriented towards application and high quality of use and has many similarities to DDD. In particular, the "building blocks" from DDD largely correspond to the design metaphors in WAM. An important idea of ​​WAM is to transfer the tools and materials that a user works with in the real world into the software. They should be available there for the user, but also in the code.

literature

Web links

Individual evidence

  1. a b Eric Evans: Domain-Driven Design. Tackling Complexity in the Heart of Software . Addison-Wesley, 2003, ISBN 978-0-321-12521-7 (English, dddcommunity.org ). dddcommunity.org ( Memento of the original from October 21, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  @1@ 2Template: Webachiv / IABot / dddcommunity.org
  2. ^ Definition of DDD according to dddcommunity.org
  3. Eric Evans: Domain-Driven Design . Tackling Complexity in the Heart of Software. Addison-Wesley, 2003, ISBN 978-0-321-12521-7 , pp. xxii (English, http://dddcommunity.org/ ). http://dddcommunity.org/ ( Memento of the original from October 21, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  @1@ 2Template: Webachiv / IABot / dddcommunity.org
  4. ^ Floyd Marinescu, Abel Avram: Domain-Driven Design Quickly . Lulu Press, 2006, ISBN 978-1-4116-0925-9 , chap. 1 , p. 4 (English, InfoQ: Domain Driven Design Quickly ).
  5. hexagonal architecture
  6. An Introduction to Domain Driven Design. In: www.methodsandtools.com. Retrieved October 21, 2016 .
  7. Anemic Domain Model
  8. Presentation at JAOO on November 6, 2007 by Eric Evans, presentation on InfoQ
  9. Eric Evans: What I've learned about DDD since the book. (Video) Domain Language, Inc., May 2009, accessed on October 23, 2010 (English, discussion of domain events from 1:00 p.m. to 28:05 p.m. Presentation recorded at DDD-NYC SIG, originally presented at QCon London 2009) .
  10. Domain-driven Design Quickly, Chapter 5, pages 67ff
  11. ^ Dan Haywood: Domain-Driven Design using Naked Objects . Ed .: Pragmatic Programmers. Pragmatic Programmers, 2009, ISBN 978-1-934356-44-9 (English, Domain-Driven Design using Naked Objects ).