In the design and practice of microservices, many people may agree that “how many microservices can be divided into single applications is the design focus of microservices”.
A lot of people spend a lot of energy on unbundling microservices and attribute the design of microservices to how well they are unbundling microservices.
But is that really the case? Not really!
When Martin Fowler proposed microservices, he mentioned an important feature of microservices: an evolutionary architecture.
The evolutionary architecture supports incremental, non-destructive change as a first principle, while supporting multi-dimensional change at the level of application architecture.
So how do you determine if microservice design is reasonable?
Actually very simple, you just have to see if it meet such situation: with the development of the business or demand change, during the domain model and the service are continually split, or combined into a new micro service process, not greatly increase the cost of software development or maintenance, and the structure evolution process is very easy and simple. This is the focus of microservice design, but also the most important problem in microservice design.
In microservice design, many teams split centralized single application microservices into multiple so-called “microservice” deployment packages based on their business functions. However, the code in these “microservices” still adopts the traditional three-tier architecture design pattern, that is, the code is still highly coupled and the logical boundary is not clear, we call it “small single microservices”.
Three-tier architecture: presentation layer, business layer, data access layer.
As we evolve from monolithic architectures to microservices architectures, do we need well-defined microservices? Or do you need lots and lots of small individual microservices?
As new requirements are put forward and businesses continue to develop, these “small units and micro services” will slowly expand and become complex.
When one day need the expansion of “micro monomer service” in the part of the business functions are split out, or some functions need consolidation with other services, you will find that these seemingly boundary clear micro service, it is difficult to split again, imperceptible in it has become a “fat fat” big monomer. You’ll have to refactor from large to small over and over again, and the refactoring process can be painful, hard to choose from, and can cause you to throw away a lot of code that you thought made sense.
At this point, it becomes clear that while the business boundaries are clear, the code boundaries are ignored. This singleton microservice only defines the boundary of one dimension, namely, the business physical boundary between microservices. Although the microservice architecture has been upgraded, it still remains in the design thinking of single architecture in essence. In the continuous evolution of microservitization, it is likely that there will constantly be a rhetorical question: “Is microservitization really necessary? Microservitization is not as good as traditional monolithic apps…”
When designing microservices, we should not only consider the business physical boundary between microservices, but also define the logical boundary and code boundary within microservices.
Everyone wants clear borders, but how do you get them?
DDD?