Should not be missed! What is Domain Driven Design? Why is it so hard to land?

introduction

Domain-driven design is not a new architectural design theory, it has been more than ten years since Eric Evans proposed it. Due to the rise of microservice architecture, DDD is often used to guide the demarcation of microservice boundaries and re-enter the field of vision of the software development public. The concept and application of DDD are relatively mature in foreign countries, but are still in the initial stage of development in China. In recent years, the discussion and application of DDD has become increasingly popular in many communities and enterprise organizations in China, and many architects and developers are full of enthusiasm for learning and practicing DDD. Like agile, different teams have different levels of awareness and practice, and some are successful, most may fail.

Domain Driven Design, or DDD for short, was first proposed in Eric Evans' 2004 book "Domain-Driven Design: Tackling Complexity in the Heart of Software". Domain-Driven Design is a methodology used to guide software design and a design thinking style for addressing software complexity, aiming to accelerate the development of software projects that must deal with complex domains.

The first step in practicing DDD is not how to write code, but the first need to align the knowledge of domain-driven design . The follow-up series of articles will discuss domain-driven design from different perspectives, in order to help you have a deeper understanding of it and apply it in practical R&D work.

Talk about problem space, solution space, domain model

problem space and solution space

Problem space: Problem space is a series of problems faced by the business in the current environment and the requirements behind the problems. It is usually the collection, description and analysis of problems and requirements led by experts in the business and product fields. The problem space defines the context of the problem we are trying to solve. This context is not unique to software engineering or domain-driven, but is a common element. Engineering practice must be in a certain context.

Solution Space: Solution Space, the solution space is the solution for the problem space, which belongs to the engineering realization stage and is designed by technical experts.

The software development process can be regarded as a mapping transformation from problem space to solution space in essence: problem space, find out business challenges and analyze the solution space for related demand scenarios and use cases, and design and implement through specific technical tools and means

Domains, Models, and Domain Models

Domain: Domain

A "domain" is a "collection of knowledge or activities", and relative to a software system, a domain is the real-world problem area to be solved by a software application. A domain corresponds to a problem space and is the sum of business requirements within a specific scope boundary.

Domain Model: Domain Model

Abstraction is an ability to simplify complexity, a tool for human beings to understand the world, and a biological instinct. Under the premise of limited brain capacity, it is impossible for humans to store all the details of memory, and the massive information has exceeded the storage limit of the human brain and cannot be accommodated and effectively acquired. Abstraction enables humans to shield irrelevant details and extract high-level effective information for memory storage. Just imagine, if there is a breakthrough in brain-computer interface technology, a massive and efficient computer cluster is linked behind the human brain. With the enhancement of this infinite storage, calculation and retrieval ability, "abstract ability may be weakened".

Models are used to represent some aspect of reality or ideas that people are concerned about, and are essentially the product of an abstraction process that abstracts away aspects that are closely related to the solution while ignoring irrelevant details.

Focusing on the field of software engineering, in order to build a software system that meets the requirements, the development team needs the knowledge involved in the software-oriented domain may be very large and complex, and the model is an effective tool to solve this information overload problem.

The process of designing a model for a domain is domain modeling. The purpose of domain modeling is not to establish a model that is 100% in line with "reality". In theory, we cannot achieve this complete modeling of reality, but only Some sort of simulation of reality.

The output of domain modeling is the domain model, which is a visual representation of key things and their relationships in a specific domain, and belongs to the category of solution space. In order to accurately define the abstract model that needs to be solved to solve the problem, and to unify the cognition of the construction goal of the software system, it is the mapping and transformation of business function scenarios in the software system. A domain model is not the knowledge in the minds of domain experts, but a rigorous organization and selective abstraction of that knowledge.

At the same time, domain models are not some special diagrams, words or codes, but the ideas they convey. Diagrams, words or codes can be used as representations or forms of communication for models, but they are not models, but model views of different dimensions. .

Domain Driven Design

Domain-driven design emphasizes the importance of the domain model, and ensures the consistency of the domain model and program design through model-driven design. Domain-driven design first extracts a unified language from business requirements, and establishes a domain model to guide program design and coding implementation; finally, it discovers implicit concepts through refactoring, and continuously solves new problems related to the domain model. In essence, Domain Driven Design also maps from the problem space to the solution space.

Domain-driven design combines macro and micro levels of design, corresponding to strategic design and tactical design in the domain-driven concept, respectively.

Domain-Driven Design: Strategic Design

The original intention of strategic design is to maintain the integrity of the model, which is mainly considered from the following two aspects:

Problem domain: disassemble the problem scale, divide it into different types of subdomains, and identify the core domain and other subdomains.
Solution level: Divide bounded context and context map to reasonably decompose the problem domain, determine context boundaries and the relationship between them.

Domain-Driven Design: Tactical Design

The original intention of strategic design is to maintain the integrity of the model, decompose the entire software system into multiple bounded contexts through strategic design, and then carry out tactical design for each bounded context. Tactical design for each Bounded Context. The construction elements of Model-Driven Design provided by Eric Evans and the relationship between the elements are shown in the following figure:

• Entity: Entity, unlike traditional objects defined by attributes, entity objects are distinguished by unique identifiers and have a continuous life cycle.
• Value Object: Value Object, a value object is an object that has properties and is immutable, but does not have a unique identity.
  Domain Events: Domain Events are used to record discrete events related to model activities in the system. Although all events in the system should be able to be tracked, only the event types that are concerned by domain experts create domain events.
• Aggregate: Aggregate, an aggregate object is an aggregate of entity and value objects, and an aggregate has a unique root, the aggregate root. External objects no longer directly access individual objects or entities inside the aggregate, but directly access the aggregate root and use the aggregate root to pass instructions to the corresponding grouping.
• Domain service: Domain Service, some domain logic is not suitable for assigning to a specific entity object, these operations can be encapsulated into domain services
• Repository: Repositories, Repository is not a configuration repository, it provides a global interface to access all entity classes and value objects within a specific aggregate, and should include methods to create, modify, and delete objects within the aggregate.
• Factory: Factories, the factory encapsulates the logic of creating complex objects and aggregations, shielding the client from the complexity of creation

The above-mentioned DDD tactical design patterns identify some key patterns in design, but it does not mean that they must be strictly used and followed, nor that all tactical design patterns are followed to conform to domain-driven design. Because the key to practicing DDD is not the implementation of this tactical level model, but the adherence to its macro domain-driven design ideas, such as unified language, consistency between domain models and code, subdomain and context splitting and mapping, Separation of domain model from technical concerns, etc. In addition, with the continuous development of DDD, some new construction models have emerged, and the old construction models may not meet the requirements of team development.

Why is Domain Driven Design so difficult to implement?

1. Requires robust domain knowledge, relying on the support of domain experts in the project

• Even the most skilled developers are useless if there are no domain experts on the team who are familiar with the domain knowledge required by the application. In some cases, domain-driven design requires one or more outsiders to act as domain experts throughout the software development life cycle. In some cases, domain-driven design requires collaboration with external team members (acting as domain experts) throughout the software development lifecycle.
• There are also challenges in applying DDD in innovative businesses. Due to the uncertainty of the business model, the frequency and magnitude of changes in business requirements are large, and there is also a lack of domain experts in new fields. The entire business is in an exploratory mode, and it is difficult to establish It is a relatively stable and highly reusable domain model.

2. Emphasis on continuous iteration and continuous integration can lead to obstacles for teams that lack iteration experience and prefer a waterfall model

Domain-driven design practices rely on continuous iteration and continuous integration to build highly scalable projects, but this iteration and continuous integration-based time can be a hindrance to landing in some teams, especially if past experience is built on rigidity On the development model, such as the waterfall model.

3. Not suitable for technically oriented applications

Domain-driven design is suitable for applications with very high domain complexity (complex business logic), but not for domains with low domain complexity but high technical complexity. DDD emphasizes the need for domain experts in order to construct a unified language and domain model that the project depends on, but if the technical complexity of the project is high, it is a challenge to understand the domain. Can cause problems when all team members do not fully understand technical requirements or limitations

4. The team pays too much attention to tactical design, resulting in deviation from practice guidelines and principles

The team's awareness of domain-driven design is not enough, and its energy is not focused on core principles such as problem domain splitting, unified language, and separation of model and technical concerns. Instead, it is triggered from the perspective of implementation from the beginning, and it overemphasizes the tactical design pattern. landing, thus falling into endless technical details

Author: Ni Xinming