Original address: https://microservices.io/patterns/decomposition/decompose-by-business-capability.html
Background introduction
Suppose you are developing a large and complex microservice architecture application. The goal of the microservice architecture is to design a program into a set of loosely coupled microservice applications, and accelerate software development through continuous delivery and deployment.
The microservice architecture achieves this in two ways:
- Simplify testing and ensure that components can be deployed independently.
- Small (6-10 people) and autonomous teams collaborate with each other to complete software development. Each small team is responsible for one or more microservices.
But if you want to enjoy these benefits, you must split the service. Microservices should be small enough to be developed by a small team and easier to test. An important guiding principle of object-oriented design (OOD) is the Single Responsibility Principle (SRP). SRP defines the responsibility of a class as the reason for changing this class, and stipulates that a class should have only one reason for change. SRP can be applied to service design to design more cohesive services and implement a small number of strongly related functions .
Splitting microservices also requires splitting in a way that most new and changing requirements affect only a single service. This is because changes that affect multiple services require coordination across multiple teams, which slows down development. Another useful principle of OOD is the Common Containment Principle (CCP), which states that classes that change for the same reason should be in the same package. In this way, when requirements change, only a small amount of code needs to be modified, and ideally only one package needs to be changed. This kind of thinking is also instructive when designing services, and it will help ensure that each change affects only one service.
problem
How to decompose the application into microservices?
Considerations
- The overall architecture needs to be stable
- Microservices must be cohesive , that is, each microservice should implement a small number of strongly related functions
- Microservice design needs to follow the principle of common closure , and the content that will be changed together needs to be packaged into a microservice to ensure that each change only affects one microservice.
- Microservices must be loosely coupled . Each service is an API that encapsulates its implementation, and the implementation can be changed without affecting the client.
- Microservices need to be testable
- Each microservice can be developed by a small team
- Every team that owns one or more microservices must be autonomous. Teams must be able to develop and deploy their services independently , reducing the cost of collaboration with other teams.
solution
Define the service corresponding to the business function . Business function is a concept in business architecture modeling, generally refers to a thing to do to create value. Business functions usually act on business objects , such as:
- Order management is responsible for executing order-related operations
- User management is responsible for user operations
For example
An online store usually includes the following business functions:
- Product catalog management
- Inventory management
- Order management
- Delivery management
- …
Design microservices corresponding to these functions:
benefit
This model has the following advantages:
- Stable architecture, because the division of business functions is relatively stable. Splitting microservice modules according to business functions will also be stable. It will not happen that one microservice will be added and one will be removed.
- The development team is cross-functional, autonomous, and organized around delivering business value rather than technical features.
- Microservices are cohesive and loosely coupled.
problem
The main question is how to design business functions ? You need to understand the business to design a good business function . General business functions are designed in accordance with the purpose, structure, business process and professional fields of the analysis company. Continuously change and expand the boundaries of business functions through iterative processes . Generally, you can start designing business functions from the following aspects :
- Organizational structure of the company: The organization design of a company is designed according to business functions, and different groups within the organization may correspond to different business function groups.
- High-level domain model: General business functions will be designed as some operations or services for certain domain objects.
Related patterns
Another design mode that you can choose to replace is the split mode by subdomain