This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

The introduction

The author has used DDD dome-driven design for architecture design in many projects he has experienced, especially in business sorting, mid-stage planning and micro-service division. DDD is an important architecture design methodology, which has a very good guiding role in ordinary architecture design. From the beginning of this article, the author will explain his understanding of DDD and how to practice DDD in the actual project through a series of articles. This article begins a series of articles by talking about some of the basic concepts and common methods of DDD.

Who exactly is DDD?

Software design method

Our software development patterns fall into several categories, DL driven development, data driven design, and DDD driven design. It actually represents our different stages of development, and there’s a sense of going from rough to elaborate. This is like a budding new workplace, to have some experience of the old bird, and then to the elite beat strange upgrade process. Let’s take a look at each of these software development patterns.

DL driven design: namely, DeadLine driven development, given a DeadLine, as long as you finish the required functionality before the DL can, as to design what doesn’t concern, basic lack of process management, pursuit of short-term business objectives, so it is possible that the corresponding code is one tuo tuo, difficult to maintain, to buried the huge technical pit in the future.

Data-driven design: this is probably the most commonly used software design method. After the demand comes, the database table is designed first, and then the corresponding business process is connected through the data flow, which can basically cope with most application service scenarios.

DDD domain-driven design: as the systems we are in contact with become larger and larger, and more and more subsystems are involved, traditional software design methods can no longer meet our needs to deal with complex system design. DDD provides a methodology for domain modeling and analysis of large and complex systems.

Let’s skip the first approach and look at data-driven and DDD domain-driven design. In fact, the biggest difference between these two design methods is the change of design ideas. Data-driven design focuses on specific business data bearing. It first determines the corresponding business data entities, then completes the design of database tables, and then connects these data together through specific business processes to complete the software design. In some simple and small systems, this design approach is perfectly adequate.

However, with the continuous development of business, the implementation of micro-service practice, especially in the large factory extremely complex and huge business. Data-driven design alone is difficult to achieve. DDD focuses on the domain model, which drives the software design of the entire system, decouples the domain model from the data model, and clarifies the business boundary, so as to better guide us to complete the architecture design of complex systems.

DDD

The DDD domain-driven design pattern was introduced from the description of different software design approaches above, so let’s take a look at what DDD really is. The so-called DDD is Domain Driven Design, which literally means Domain Driven Design. It’s not really a new thing, Back in 2004 renowned modelling specialist Eric Evans in his influential book “Domain-Driven Design – Complexity in the Heart of Software” (Domain-Driven Design: Solutions to software core complexity have been proposed. But in fact, the domestic Internet companies to DDD application is not much.

DDD is not a form of architecture, but a guiding principle for architectural design and a methodology for dealing with complex domain problems. He can help us design high quality software models. Especially in the scenario of complex, large software systems, DDD can play its unique role.

In addition to understanding DDD, we would like to apply the ideas of software architecture design to our practical work, but this is not an easy thing to do. To truly implement DDD, the following two conditions must be met

1. Unified understanding: DDD is not a one-man show. It requires the whole team to have a deep understanding and recognition of DDD from top to bottom. Although DDD is an architectural technology practice, its positive value will eventually be transmitted to the business side to form corresponding business value.

2. Implementation: it is not enough to have theoretical guidance and profound understanding. We must also carry out the implementation in practical work.

In addition to explain, DDD itself in understanding above a certain threshold, even if we are to understand the various concepts, also not necessarily can make the DDD perfect landing in our practical work, because it is not just a matter of software architecture design, but also the question of how to implement the whole team, I think this is why DDD no large-scale application.

Why do YOU need DDD?

From the above, we have a preliminary understanding of DDD, which is an architectural design methodology to cope with software complexity. Let’s start with the question of what factors contribute to the complexity of software design. Because only by understanding the complexity factor can we better understand why we need to use DDD to cope with increasingly complex software system designs.

We often encounter such problems in actual project development. We often quarrel with each other about whether your group is responsible for the modification of this part of the business or the other group’s modification.

1. High business complexity

Demands are piling up, businesses are growing over time, systems are huge, and different businesses interact with each other. Take e-commerce business as an example, there are dozens of micro-service categories such as commodity service, user service, inventory service, order service, integral service, coupon service, logistics service and so on, forming a very complex business system.

In the case of multiple service systems, service boundaries are not clearly demarcated due to historical reasons, and there are various dependencies between the systems. Once a large project involving many sub-domain systems is undertaken, it is often a matter of business boundary issues between the teams.

2. Business needs change rapidly

Competition in all business sectors of the Internet industry is very fierce. Whoever can launch more convenient products more quickly and more in line with users’ expectations will grab the market and seize the market opportunities. Therefore, the corresponding business process naturally changes quickly. The business process is like this one day, the next day will be different. This constantly changing scenario and requirements presents a significant design challenge for the entire software system.

3. Difficult to collaborate across teams

A large project, in most cases, requires the cooperation of teams in various sub-domains to complete the full link of the business. If there is no unified business language, it will inevitably lead to low efficiency of communication between teams, and even the situation of diminishing layers of business communication. Repeated communication between teams also increases the cost of communication for designers and developers.

As mentioned above, we need to think about how to better implement requirements, better respond to changing requirements, and better collaborate with others when designing software architectures. As a result, the traditional data-driven design approach can no longer meet our practical needs, and it would be wonderful if there were an architectural design pattern that could support us to meet these challenges.

Therefore, to sum up, we need an architectural design methodology to guide the design of complex business systems, and DDD is a very good choice.

The value of DDD

From the above description, we have a general idea of why we need to use DDD to implement software architecture design. So what value does DDD bring to us?

Unified business Language: The use of a unified domain language eliminates differences between teams and improves communication efficiency.

Precipitate business knowledge: Precipitate domain knowledge through domain model, improve business modeling ability, and clearly express business core semantics.

Clear business boundaries: unify the understanding of each sub-domain, define requirements and realize boundaries through the domain model, surface endless team wrangles, and pull through team cognition.

Improved change response: Through the separation of domain model and data model, the core business invariant and the change of requirements are effectively isolated to improve the ability of architecture to change.

DDD important concepts

A unified language

After qin Shi Huang unified the six states, the first thing he did was to unify writing, weights and measures and coins throughout the country. Among them, the unification of characters is to facilitate the communication of people in various regions, and to achieve the unification of China has laid the foundation.

In DDD, it is necessary to establish a unified business terminology system among domain experts, design teams, and R&D teams, so that everyone can reach agreement on the description level of domain knowledge, so as to solve the communication and collaboration problems among various teams. The unified language here is mainly reflected in two aspects:

(1) Unified field terms: A domain term is in the field of each object in the named consensus reached, for example in the field of inventory SKU, each team all know SKU represents the inventory in and out of the unit of measurement, so that at the time of business discussion, at the mention of SKU are known brought on behalf of the meaning of it, don’t need too much explanation.

(2) Unified domain behavior: Domain behavior is the behavior description of the domain. For example, the shelving action of goods involved in the inventory domain is a specific domain behavior of the domain. Therefore, we can see that domain behavior is a behavior description from the perspective of domain model rather than a specific realization perspective.

The domain model

Before we figure out what a domain model is, let’s look at the definition of a domain in Domain-Driven Design.

A domain is what an organization does and what it contains. Businesses often identify a market and then sell their products and services in that market. Each organization has its own scope and way of doing things. This area of business and the activities performed within it are domains.

This definition seems a bit confusing, but let’s go with the most familiar scene of e-mart. Electricity system in user shopping for example, users browse commodity, choose the corresponding items in order, after making orders, increase integral service user’s shopping integral, inventory service will be deduct corresponding goods inventory, coupon service to the user new coupons, logistics service will take over the follow-up of the finished product logistics information. In this typical shopping scenario, the user service is responsible for providing user information and unified management of users, so all operations about users are completed in the user domain, including the maintenance of user names, passwords and other information as well as the implementation of registration, login and other actions. Then we can think of the user service here as the user domain, which is a sub-domain in the e-commerce system.

For the domain model, we might assume that it is a large and comprehensive model that encapsulates the entire business system, but it is not, and it is very difficult to define such a model. In the actual implementation process, we are more willing to realize the establishment of domain model in each sub-domain, and the domain model is implemented in this bounded context.

Therefore, domain model is a software model for a specific business field. For example, orders, points, inventory and distribution in the e-commerce business field are all subdomains of the e-commerce business field. Domain model describes real business scenarios through object models and accurately expresses business semantics, which is the currency in real business scenarios.

Domain experts, designers, and developers need to have a common understanding of the domain model across the business team. There are different domain models in different subdomains, so how do we distinguish between different domain models? In fact, we distinguish between different domain models by bounding context.

Bounded context

This concept, how to put it, is both easy to understand and hard to understand. Bounded context is an explicit conceptual boundaries, our domain model is the border, we all know that the domain model is to use the same language to describe software model of each domain model has a corresponding properties and actions, these properties and actions need to be in a specific context is the meaning of the specific. For example, in the stationery world, notebook is a paper recording tool. The same word is notebook, but in the 3C world, it refers to the laptop that we often use. The same name but in different boundary contexts can mean completely different things. So, in effect, a bounding context creates a modeling boundary for the team within which the team implements the solution.

Through the example above we can understand the bounded context as a kind of farm in circles, some circles is a pig, some circles are used to grow vegetables, if not bounded context that the pig could eat vegetables, but after a fence (bounded context), we can feed or irrigation in different circles, They don’t interfere with each other so that the farm can run well. The circles and fences of the farm can actually be seen, so domain boundaries are an abstract view in software systems.

As shown below, the business domain of e-commerce includes sub-domains such as order, goods invoice and inventory, as well as the corresponding bounding context.

conclusion

This article mainly focuses on what is DDD, and analyzes the complexity of software architecture design, so we need DDD this complex architecture analysis method to assist us to complete. Now that we have an overview of what DDD does and some important concepts, the next article will take a look at DDD implementation steps and several common practices.

PS

Please feel free to discuss in the comments section. The nuggets will draw 100 nuggets in the comments section after the diggnation project. See the event article for details