Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about the strategy of decomposing the system into micro-services, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

A few years ago, Vladik Khononov and his team decided to start using microservices, but a few months later they found themselves in a huge mess. The reason for this, he pointed out at the recent DDD eXchange 2018 conference in Skills Matter in London, is that they are focused on adopting cool new technologies rather than on more basic things, such as modularity and how to achieve it. They put their energies into serverless frameworks, platforms, and messaging mechanisms, but they think very little about how to break the system down into microservices, in other words, how to find boundaries and divide different functions by boundaries.

Khononov is Internovus's CTO, and for him and his team, the initial creed is that the smaller the service, the better it will be. This led them directly to build a distributed monolithic structure (distributed monolith), and over the next few years they tried to get rid of these tiny services and evaluated different decomposition strategies.

Bounded context (Bounded context)

Khononov points out that common language (ubiquitous language) is a basic practice in domain-driven design (Domain-Driven Design,DDD), and one way to implement this practice is to talk to domain experts in their language. Sometimes, you will find that they have different mental models for the same business concept, or use the same terminology to describe different ideas, which indicates that these ideas belong to different boundary contexts. From the beginning, Khononov and his team have used these methods to discover the boundaries that define services, each of which becomes a service. He pointed out that these services represent a wide range of business areas, sometimes resulting in a bounded context covering multiple business subdomains.

Business subdomain

Next, they use these business subdomains as boundaries and then create a service for each business subdomain. In Khononov's experience, establishing an one-to-one relationship between subdomains and services is a very common way for the DDD community, but they are not satisfied with this, but continue to strive to implement smaller services.

Business entity

Delving into the subdomain, they found business entities and processes, and then they extracted them into separate services. At first, this ultimate approach failed miserably, but Khononov pointed out that it had greater success in subsequent projects.

In terms of these three strategies, Khononov points out that using bounded contexts can help them find the most effective cell boundaries, however, although it is a feasible working model, he believes that this approach does not well match the idea of microservices. When choosing between business subdomains and entities, he believes that the best level of decomposition depends on the system being built and its use cases. He stressed that the concept of microservices is not really about how to implement within a single service, but about how services are intersected and coupled.

The threshold at which the system is decomposed into microservices is defined by the use case to which the microservice belongs.

Khononov has not yet found an easy way to evaluate the design of a system, but he believes there are enough heuristic design guidelines to help us break down the system into micro-services. The items that he thinks are most useful include:

Always decompose to the bounded context level. Don't break it down further unless you have a good reason. Distributed systems have their own challenges.

The core subdomain is the area where the company makes money. When decomposing, make sure to acquire domain knowledge and have appropriate subdomains.

Purchase or adopt a common subdomain. They have solved some problems, and if they do so themselves, they will have no competitive advantage.

In order to support the core domain, we need to support subdomains, but this does not add any competitive advantage. They are usually very stable and simple and can be further decomposed at an early stage until they become physical services.

Adopting consistent requirements helps us find functions or methods that must be placed in the same service.

Make sure the event is explicit and self-describing. Consider using private events as implementation details in a service and more stringent public events as the exposed interface of the service.

Look for services that change at the same frequency, and they may be able to merge to reduce complexity.

Evaluate the interface for each service. If you feel that the scope of service is too wide, then it may be able to split into smaller services, mainly in terms of integration, reconsidering the evaluation boundary to simplify the design of the entire system.

In conclusion, Khononov pointed out that as the average size of services in the system becomes smaller and smaller, you will move from a large mudball-like monolithic system to a relatively large service through a bounded context, and then into a micro-service. However, he stressed that if you continue to make the service smaller, it will eventually form a big distributed mud ball.

After reading the above, do you have any further understanding of the strategy of decomposing the system into micro-services? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.