Microservice architecture design pattern reading notes Chapter 2 service splitting strategy




This is a book about microservice architecture design. This is my study note. First, some symbols are explained:

() for supplement, it is generally the content in the book;
[] is the author’s note;

1. What is the microservice architecture

1.1 4 + 1 view of software architecture


1.2 application requirements at two levels

  • Functional requirements;
  • Non functional requirements, also known as quality attribute requirements. (including scalability, reliability, maintainability, testability and deployability) [this is why architecture is important]

1.3 layered architecture style

The popular three-tier architecture is the hierarchical architecture applied to logical views, as follows:

  • Presentation layer: contains the code to implement the user interface or external API;
  • Business logic layer: including business logic;
  • Data persistence layer: realize the logic of interaction with database;

Its disadvantages are:

  • Single presentation layer: unable to show the fact that the application may not be called by a single system;
  • Single data persistence layer: unable to show the fact that the application may interact with multiple databases;
  • The business logic layer is defined as a data persistence layer: in theory, this dependency prevents testing business logic without a database;

1.4 hexagon on architectural style

Hexagonal architecture is a substitute for hierarchical architecture style [to solve the disadvantages of hierarchical architecture], and hexagonal architecture chooses to organize the logical view in a business logic centered manner.


  • The business logic has one or more ports, which define a set of operations about how the business logic interacts with the outside world.
  • There are two kinds of ports: inbound port and outbound port;
    • Inbound port is the API exposed by business logic (such as service interface, which can be accessed externally);
    • Outbound port is the way that business logic calls external systems (such as repository interface, defining the set of data access operations);
  • There are two types of adapters around the business logic: inbound adapter and outbound adapter;
    • Inbound adapter: process external requests by calling the inbound port (such as spring MVC controller, which implements rest interface or a set of web interfaces);
    • Outbound adapter: process requests from business logic by calling external applications or services (such as implementing data access object Dao class);


  • Separate the business logic from the logic of the presentation layer and data access layer contained in the adapter, making it easy to test the business logic separately;
  • Reflect the architecture of modern applications;

1.5 what is service

Service is a single and independently deployable software component, which realizes some useful functions.


  • The service has API to provide the client with access to functions;
  • API consists of commands, queries and events;
  • Developers cannot bypass the API and directly access the methods or data inside the service (loose coupling);

1.6 architecture style of microservice architecture

  • The view it implements is composed of multiple components;
  • Components are services, and connectors are communication protocols that enable these services to cooperate;
  • Loose coupling;
  • Shared class library (which implements functions that are unlikely to change);
  • Service size is not important;

2 define the microservice architecture for the application

Defining architecture is an art, not a technology; In the real world, this is a process of continuous iteration and continuous innovation.

2.1 three step process for defining application architecture


  • Step 1: identify system operation;
  • Step 2: define the service;
  • Step 3: define the service API;

2.2 step 1: identify system operation

Abstract domain model and system operation can answer the question of “what to do” of the application, and help to promote the architecture design of the application.


2.2.1 identify the steps and matters of system operation:

  • Step 1: create an abstract domain model
    • By analyzing the frequent nouns in user stories and scenes, we can iteratively analyze them into some classes of this domain model;
  • Step 2: define system operation
    • There are usually two kinds of requests that must be identified by the system:
      • Command type: system operation of creating, updating or deleting data;
      • Query type: system operation for querying and reading data;
    • The entry point of system operation is to analyze the verbs that frequently appear in user stories and scenes;
    • Command specifications (parameters, return values and domain model classes) and behavior specifications (preconditions and postconditions) need to be considered;

2.3 step 2: define service

2.3.1 service splitting based on business capability

Splitting steps:

  • FirstDetermine business capabilities, usually refers to what the business of the organization does, which can be obtained through the analysis of the organization’s objectives, structure and commercialization process;
  • After determining the business capability, you canDefine services for each competency group, this is a very subjective judgment;
  • The following figure shows the mapping of ftgo application from capability to service:

2.3.2 service splitting according to sub domain

Also known as: Domain Driven Design decomposition application method

Some concepts:

  • Domain model: it contains the knowledge of a domain in the way of solving specific problems;
  • DDD common language: defines the vocabulary of relevant teams in the current field, which has two important concepts:
    • Sub domain: it is a part of the domain, and the identification method is similar to the identification business;
    • Bounded context: the boundary of the domain model. Usually, each bounded context corresponds to one or a group of services;

Splitting steps:

  • Define subdomains through DDD;
  • Corresponding the sub domain to each service;
  • The following figure shows the mapping of ftgo application from sub domain to service:


2.3.3 guidelines for splitting

Inspired by face object design principles.

  • Single responsibility principle: each class defined should have only one responsibility;
  • Closure principle: if for some reason, the modification of two classes must occur successively, they should be placed in the same package;

2.3.4 difficulties in splitting individual applications into services

  • Network delay
    • Description: the specific decomposition of services leads to a large number of round-trip calls between two services;
    • Solution: combine multiple related services and replace interprocess communication with function call of programming language; Or implement the batch API to obtain multiple objects in a round trip;
  • Synchronization of interprocess communication leads to reduced availability
    • Description: when using rest protocol to synchronously call other services, the service availability will be reduced;
    • Solution: refer to Chapter 3 asynchronous messages;
  • Maintain data consistency between services
    • Description: when a system operation needs to modify the data of multiple services, the data consistency needs to be maintained;
    • Solution: refer to Chapter IV saga related;
  • Get consistent data view
    • Description: it is impossible to obtain a truly consistent data view across multiple databases;
    • Solution: (in practice, it rarely brings real problems);
  • God class hinders separation
    • Description: God class is a global class used in the whole application. It is usually bound to the state and behavior of multiple services;
    • Solution: refer to 2.3.5 God class hinders splitting in this chapter, taking the order class of ftgo as an example;

2.3.5 God class hinders splitting

When defining a microservice architecture, God classes must be identified and eliminated.

Problem description: in ftgo application, order class is related to order processing, restaurant order management, meal delivery and payment, and has a complex state model, as shown in the following figure;



  • Package the order class into the library and create a central order database (violating the loose coupling principle);
  • Encapsulate the order database in the order service, which is called by other services to retrieve and update orders (the problem is that the order service will become a pure data service and a domain model with little or no business logic);
  • [recommendation] DDD is used to treat each service as a separate sub domain with its own domain model, so that each service related to the order has its own domain model and its corresponding order class version, as shown in the following figure;

Delivery Service的领域模型
Kitchen Service的领域模型

Order Service的领域模型

2.4 step 3: define service API

2.4.1 steps and matters for defining service API

  • Step 1: assign system operations to services
    • That is, determine which service is the initial entry point of the request;
  • Step 2: determine the API required to support service collaboration
    • Some system operations are completely handled by a single service; It may also be scattered around multiple services.

3. Summary of this chapter

  • Architecture determines various non functional factors of software, such as maintainability, testability, deployability and scalability, which will directly affect the development speed;
  • Microservice architecture is an architectural style, which brings higher maintainability, testability, deployability and scalability to applications;
  • Services in microservices are organized according to business requirements, according to business capabilities or sub domains, rather than technical considerations;
  • There are two decomposition modes:
    • Decompose by business capability, which originates from business architecture;
    • Based on the concept of domain driven design, it is decomposed by sub domain;
  • God classes can be eliminated by applying DDD and defining a separate domain model for each service. It is God classes that cause intertwined dependencies that hinder decomposition.


Newcomer production, if there are mistakes, welcome to point out, thank you very much!Welcome to the official account and share some more everyday things.If you need to reprint, please mark the source!
Microservice architecture design pattern reading notes Chapter 2 service splitting strategy