The concept of Domain-Driven Design (DDD) is originated in 2004 in his most influential book “Domain-Driven Design – Complexity in the heart of” released by renowned modelling expert Eric Evans Domain-driven Design: Solutions to Software core Complexity. , which introduced the concept of domain-driven design (DDD).

Domain-driven design is generally divided into two phases:

  1. Using a common language that domain experts, designers and developers can all understand as a tool for mutual communication, we can find and dig out some major domain concepts in the process of continuous communication, and then design these concepts into a domain model.

  2. The software design is driven by the domain model, which is represented in code. The initial details of domain requirements are worked out at the functional level through discussions among domain experts.

    Domain-driven design tells us that it is very important and necessary to build a domain model when implementing a business system through software, because the domain model has the following characteristics:

    1. Domain model is an abstraction of a domain with a certain boundary, which reflects the essence of users’ business needs in the domain. Domain models are bounded, reflecting only what we care about in the domain.

    2. The domain model reflects only the business and is independent of any technology implementation; The domain model can not only reflect some entity concepts in the domain, such as goods, books, employment records, addresses, etc. It can also reflect some process concepts in the field, such as fund transfer, etc.;

    3. The domain model ensures that the business logic of our software is all in one model, all in one place; This helps improve software maintainability, business understanding, and reusability;

    4. Domain models can help developers translate domain knowledge into software constructs relatively smoothly.

    5. Domain models run through the entire process of software analysis, design, and development; Domain experts, designers, and developers share knowledge and information through domain models. Because everyone is facing the same model, so it can prevent the requirements from going out of shape, so that software designers and developers can make the software really meet the requirements;

    6. It is not easy to establish the correct domain model. It requires the active communication and joint efforts of domain experts, designers and developers, so as to deepen the understanding of the domain and refine and improve the domain model continuously.

    7. In order for the domain model to be visible, we need to represent it in some way; Diagrams are the most common way to express domain models, but they are not the only way. Code or text descriptions can also express domain models.

    8. Domain model is the core of the whole software and the most valuable and competitive part of the software. Domain models that are well designed and meet business requirements can respond more quickly to changes in requirements;

What exactly is a “domain”?

So the last two words of “domain-driven design” make sense, but what exactly does “domain” mean?

By analyzing the business, DDD finally constructs a “domain” and designs a full “domain model” rich in business behaviors.

In DDD, “domain” refers to a business area. For example, in an e-commerce system, there may be “goods domain”, “order domain”, “logistics domain”, “warehousing domain”, and so on. The DDD uses the strategy section to guide us in dividing the business areas by business and differentiating which areas are core and which are supporting and generic areas. We will explain this in more detail in a later article in this series.

The domain model refers to the carrier objects of the business, such as “goods”, “orders”, and so on. These objects have methods that have business meaning, such as “goods. Add to cart “method. We condense the main business logic into domain objects so that what an operation does is clear and easy to maintain.

Simply put, domains and domain models are more intuitive representations of business, putting business down to system architecture and code design.

Why do YOU need DDD?

“Even if we don’t have bugs in our software, that doesn’t mean the software model we design is good.” Using DDD can make our software design more reasonable, but not only that.

For a business complex system, using DDD has the following benefits:

  • Developers work with people familiar with the business to enhance collaboration between different roles on the team;
  • Helps business people and developers sort through complex business rules;
  • Developed software is able to accurately express business rules, design is code, code is design;

When do YOU need DDD?

There is a cost to using DDD, and your team members need to have some basic DDD knowledge, preferably some DDD experience.

To do anything, we need to measure costs and benefits, and the selection of technical solutions is no exception. DDD has a cost, but it also provides obvious benefits.

In general, DDD is suitable for “business complex” systems that “need maintenance and extension.”

First, let’s look at what business complexity means. If your system only needs to CRUD a few simple tables, you don’t need TO use DDD or even develop an application. You can probably just use a database client.

As a rule of thumb, if your system has less than 30 business operations or user stories, there is not much need to use DDD. If there are more than 30 or 40, the software becomes more complex and DDD is a good place to start.

On the other hand, even though the software is not complex now, DDD can be considered if it becomes complex in the foreseeable future as it is developed and extended. Some startups may just need a simple product to test market feedback quickly, and instead of continuing to develop and maintain it, they may want to buy it again or build it from scratch, so there’s no need to waste money on DDD.

So again, when do we need to use DDD? Complex services require long-term maintenance.

conclusion

At the heart of DDD is a single word: business. All DDD tools and implementations are business – centered and business – oriented. So if you want to implement DDD well, you must recognize the value of the business, focus on the business, and understand the business.

Reference Books:

  • Domain-driven Design – An approach to software core complexity
  • DDD (domain driven design) blog.csdn.net/wwd0501/art…
  • Wangchengming.blog.csdn.net/article/det…