Abstract

The first two chapters introduce DDD target management and DDD engineering structure adjustment. This article discusses the division of microservices. Microservice is a popular backend architecture system, so how to do a good division of microservices? What is the granularity of a microservice? This article focuses on how to divide domains with DDD.

Engineering structure code

In the last article, WE introduced the (2) of landable DDD — why MVC engineering architecture has become outdated. Many friends left comments saying that there is no sample code, otherwise it is too wet and NOT very clear. So I put a sample here.

Take a blog site as an example. Page1: Blog List page: shows all the blogs posted by users

page2:

The user/blog fields displayed by different businesses are inconsistent

modeling

MVC architecture

Code written using the MVC pattern is all the way to the end. See MVC-Structure for the code

DDD

There is only one place for the blog to interact with the user. See DDD Structure for the code for OpenXXXService

MVC VS DDD

As you can see from the two dependency diagrams, the DDD dependency diagram is clearer, and the interaction between the user and blog domains is clearer, regardless of what changes have taken place in the blog domain. Depending only on OpenBlogService, MVC mode has too much interaction between user and blog. If you add other functions, these modules will be too tangled.

The increased interaction between different domains means that when a change is made and the logic needs to be modified, it is the related classes for geometric multiples that need to be modified.

For example, when the business changes, the personal Center’s blog count is the user’s published articles. This published statement may have multiple meanings as the business evolves

  1. The user has written it, it’s open to the public,
  2. Passed operation audit
  3. Blog not soft deleted. All of this logic affects the relevant queries, and the implementation of this logic may be done at the database level, in Redis, or otherwise. In MVC writing, there are a lot of things that need to be changed. In DDD, no matter how this logic changes, other domains don’t need to know, only the blog domain knows, just change the code in the blog domain.

Microservice partitioning

).

After identifying DDD as the guiding principle for our domain division, we first conducted a comprehensive analysis of our business by domain to identify which domain. Then the microservices are split according to the following criteria

  1. Domain by service rules to split,
  2. At the same time, in order to ensure the purity of the domain, we distinguish the domain service from the front desk service. Domain services are domain logic and are not directly exposed to the front end. The front-end service assembles the domain services and exposes them to the front-end.
  3. At the same time, to keep expanding, we reserved a microservice as a service incubator. For businesses with unclear domains (such as most new businesses), incubate them in this service and then spin-off them when the domain is big enough.

The following figure

Domain services: blog domain user domain growth domain incubator

According to such standards to split, after a period of time, a lot of problems exposed.

  • We are a new business, in the process of business iteration, most of the new requirements are not clear in the field, we do not know whether the iteration can continue. So, according to the previous standard, all the code was written in the growth service, which resulted in almost all the team members working on the project, and lost the significance of splitting microservices.

  • Service dependence is too serious. No matter what needs to be written, multiple applications need to be written, including 1 domain service. If there is a PC at the front desk, it needs to be developed on PC service, and mobile terminal should be displayed and developed on mobile service. The call between services needs to write RPC client interface and issue version. Because there are many people developing at the same time, version confusion and dependency problems often occur. Getting services online is also a headache, as multiple services need to be deployed to change a small requirement. An important aspect of microservices is that they are decoupled and can be deployed independently. Having an extra UI layer as a microservice is obviously not a good fit.

  • The granularity is too small. Some things do not know which service to put in, for example, users’ blog collection, whether to put in the user service, or in the blog domain.

How to solve

Do not split monomer application do not know, a split problem a lot of. So how did we solve it? See you next time.

Related reading Landable DDD(1)- Objective discussion

Landable DDD (2)- Why is the MVC engineering architecture obsolete

Landable DDD(3)- How to use DDD to divide microservices

Pay attention to [Abbot’s Temple], receive the update of the article as soon as possible, and start the road of technical practice together with the abbot