Domain-driven Design (DDD)is an approach to model complex software. The modelling of the software is significantly influenced by the technicalities of the application domain to be implemented. The term “domain-driven design” was coined by Eric Evans in 2003. Domain-driven design is not just a technique or method. Rather, it is a way of thinking and prioritizing to increase the productivity of software projects in the context of complex technical contexts. Domain-driven design is based on the following two assumptions:
- The focus of software design is on expertise and 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 oriented towards agile software development. In particular, it requires iterative software development and close collaboration between developers and experts. The purpose of any software is to support the tasks of a particular application domain. To be able to do this successfully, the software must fit harmoniously with the expertise of the application domain for which it is intended. Domain-driven design enables this by modelling basic concepts and elements of the application domain and its relationships.
Architecture is characterized by the existence of an explicit layer of business logic. This layer is intended to decouple the domain classes from other functions of the system and make them as easily recognizable as possible. Different architectural styles can be used to embed the business logic layer. These include layer architecture and hexagonal architecture.
---
The classes of the domain model contain in the domain-driven design both the data and the entire functionality of the technicality to be implemented, i.e. the entire technical logic. The anaemic domain model is therefore considered an anti-pattern because it describes a domain model without technical logic.
Domain-driven design contrasts with the less complex Smart UI development pattern. When Smart UI is used, application logic is integrated directly into the user interface. This cannot create a dedicated layer for application logic that can be reused by various components. Domain-driven design is based on several concepts that should be taken into account in modelling, as well as other software development activities. The main focus here is on the introduction of a ubiquitous language, which should be used in all areas of software creation. A language for describing the professionalism, elements of the domain model, classes and methods, etc. Domain-driven design is itself independent of programming languages, tools and frameworks. However, some several tools and frameworks support the realization of specific DDD patterns or support DDD’s approach.
Parts of the Domain-Driven Design (DDD) Model
Domain-driven Design distinguishes the following components of the domain model:
- Entities (reference objects) : Objects of the model, which are defined not by their properties, but by their identity. For example, a person is usually depicted as an entity. A person thus remains the same person when his or her characteristics change; and it is different from another person, even if it has the same characteristics. Entities are often modelled using unique identifiers.
- Value objects : Objects of the model that do not have or need no conceptual identity and are thus defined by their properties alone. Value objects are usually modelled as immutable objects, so they are reusable and redistributable.
- Aggregates : Aggregates are summaries of entities and value objects and their associations with each other into a common transactional unit. Aggregates define exactly one entity as the only access to the entire aggregate. All other entities and value objects must 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 are relationships between two or more objects of the domain model, as defined in UML. Here, not only static relationships defined by references are considered, but also dynamic relationships that arise, for example, only from the processing of SQL queries.
- Service Objects : Domain-driven design models functionalities that represent an important concept of professionalism and are conceptually part of several objects in the domain model as stand-alone service objects. Service objects are usually stateless and therefore reusable classes with no associations, with methods that correspond to the functionality offered. These methods are passed to the value objects and entities that are necessary to work through the functionality.
- Professional events : Technical events are objects that describe complex, potentially dynamically changing, domain model actions that cause one or more actions or changes in the subject objects. Professional events also enable the modelling of distributed systems. The individual subsystems communicate exclusively via technical events, so they are strongly decoupled and the entire system is thus more maintainable and scalable.
- Modules : Modules divide the domain model into technical (non-technical) components. They are characterized by strong internal cohesion and low coupling between the modules. Also, Domain-driven Design knows two other components of the domain model – Factories and Repositories. Although they do not implement expertise themselves, they are still part of the domain model because they provide critical functionality for the life cycle of the subject objects.
- Factories : Factories are used to outsource the production of specialist objects to special factory objects. This is useful if either the generation is complex (and needs associations, for example, which the subject itself no longer needs) or the specific creation of the specialized objects can be exchanged at run time. Factories are usually implemented by generating design patterns such as abstract factory, factory method, or builder.
- Repositories : Repositories abstract the persistence and search of specialist objects. Repositories separate the technical infrastructure and all access mechanisms to it from the business logic layer. For all subject objects loaded via the infrastructure layer, a repository class is provided that encapsulates the loading and searching technologies used to the outside. The repositories themselves are part of the domain model and therefore part of the business logic layer. They are the only ones to access the objects of the infrastructure layer, which are usually implemented using the Data Access Objects, Query Objects, or Metadata Mapping Layers design patterns.
The names of the business logic class corresponding to these patterns are part of the ubiquitous language and should be named accordingly. A change in the name of a specialist object by refactoring corresponds to a change in the technicality of the application.
Also, domain-driven design defines several procedures that serve to ensure the integrity of the models. This is especially necessary if several teams are to work together under different management and coordination on different technical skills, but in a large project.
Tagged With ddd data driven