This is the fourth day of my participation in the November Gwen Challenge. Check out the details: The last Gwen Challenge 2021

One, foreword

Understand business, understand business, understand business, say important things three times!!

The premise of DDD modeling is to understand the business. In order for everyone on the team to communicate on the same platform, it is necessary to understand different languages in the same language. Then you need to understand the concepts in DDD.

There are many concepts in DDD: core domains, subdomains, bounded contexts, and so on.

Second, the concept of

(1) Bounded context

A small e-commerce system can also be divided into many subsystems: order system, commodity system, inventory system, WMS system, marketing system, and more than a dozen subsystems.

The bounded context is to delineate a small area under the large system (e-commerce system). The order system is a bounded context, and the commodity system can also be considered as a bounded context.

It is to divide each small system into a boundary, to separate each system, each has its own domain and territory, not mixed together.

For a complete system, multiple bounded contexts can be divided in it first, and each bounded context can correspond to a subsystem. A small independent team is responsible for maintaining this subsystem and the corresponding bounded context.

Example: Order system, maintained by a team (20 people)

  • Generation system (five people)
  • Price system (eight people)
  • Billing system (seven persons)

A bounded context is a separate system, with a separate code repository, a separate project, a separate database, a separate test environment, a separate maintenance team, completely separate, with its own set of common language.

Remember: a bounded context represents a system.

Set boundaries about what the system does internally and what services it provides externally.

(2) General language

Common language: As the name implies, everyone on the team can communicate tools.

Here’s an example:

  • In the order system, there is a classCustomerIn the context of the bounding order system, refers to the user who placed the order.
  • In the procurement system, there is a classCustomer, refers not to the user who places the order, but to the wholesaler’s customers who make bulk purchases.

The same Customer has different meanings in different systems (in the bounded context).

In the context of different systems, a set of nouns (classes) is defined that represent the common language of the boundary.

Therefore, it is necessary to define a set of common Chinese and English terms and interpretations for various core concepts in this bounded context.

Only the developers of several systems in this bounded context will understand all the nouns in the same set of common languages, and everyone will understand the noun Customer in the same way.

Common language: Everyone on the team agrees on what these Chinese and English terms mean.

Development process:

  1. After understanding the system requirements from the PM (product manager). Abstract and summarize, design a set of DDD theory in accordance with the bounded context, general language, according to the DDD theory of the system business modeling.

  2. Technical design: Design the tables in the database based on the results of DDD business modeling. In plain English, write the class (interaction) first, then design the table.

    Design THE DDD business model, divide the system, design classes, design tables, and write codes to achieve the system interaction flow in line with DDD.

Problem: This is similar to doing requirements analysis first, drawing UML class diagrams, sequence diagrams, component diagrams, etc.

(3) subdomain

The concept of domain is the primary focus of DDD modeling.

Subdomains can be divided into:

In fact, it’s a large system, and you need to do integration between domains, integration between large systems. Divide services within each domain.

  • Core domain: the sub-domain that determines the core competitiveness of the product and the company is the core domain, which is the main factor of business success and the core competitiveness of the company.

  • Support domains: Subdomains that contain neither functionality that determines the core competencies of the product and company, nor common functionality.

  • Generic domain: A generic functional subdomain that is used by multiple subdomains at the same time without much personalization appeal is a generic domain.

    For example, the HR system, OA system, CRM system, and permission system have common solutions. You can find third-party vendors to purchase and integrate, or do it in-house.

What is core domain, non-core domain?

  • Core domain: a system at the very core of a company, such as merchandise, order, inventory, etc.
  • Non-core domain (support domain) : non-core system, or support domain, in the company, such as rival data crawler system, third-party price comparison system,BIReport system, etc.

Does not support the company’s core process operation, is mainly the icing on the cake system.