# Ch2. Decomposition strategy

## 2.2 Define an application's microservice architecture


* three step process to decompose:
* step1.Identify system operations
* 服務的使用場景(an abstraction of a request that the application must handle)
* step2.Identify services: 切分相同性質形成服務
* by business capability
* around domain-driven design subdomains(DDD)
* step3.Define service APIs and collaborations
* 決定服務間的相依關係
* decide which IPC implement API in step1

* obstacle:
* network latency: too many round-trips between services.
* low availability: synchronous communication between services reduces availability
* data consistency across service: solve by SAGA
* eliminate God class: solved with DDD, segregate into services

### 2.2.1 Identifying the system operations

#### a. two step process:
##### step 1: create a high-level domain model
* domain model: nouns of the user stories
* 簡單的high-level domain model, 用意是釐清各domain的交互作用

example

Given a consumer
And a restaurant
And a delivery address/time that can be served by that restaurant
And an order total that meets the restaurant's order minimum
When the consumer places an order for the restaurant

domain model: Consumer, Order, Restaurant, and CreditCard


##### step 2: define the system operations in terms of the domain D
* system operations: verbs from scenario
* command: CUD
* query: R


precondition: given
postcondition: then

#### b. event storming
each system operation is described in terms of its effect on one or
more domain objects and the relationships between them

### 2.2.2 Defining services by applying the Decompose by business capability pattern

* business capability: The set of capabilities for a given business depends on the kind of business.

#### BUSINESS CAPABILITIES DEFINE WHAT AN ORGANIZATION DOES

* "what to do" rather than "how to do"( http/ gRPC / message)

#### IDENTIFYING BUSINESS CAPABILITIES

* identified by analyzing the organization’s purpose, structure, and business processes
* capability decompose into sub-capbilities

Order taking and fulfillment
– Order management—Enabling consumers to create and manage orders
– Restaurant order management—Managing the preparation of orders at a restaurant
– Logistics
– Courier availability management—Managing the real-time availability of couriers to delivery orders
– Delivery management—Delivering orders to consumers

#### FROM BUSINESS CAPABILITIES TO SERVICES

* map the capability, sub-capbility to services


* benefit: organizing services around capabilities is that because they’re stable, the resulting architecture will also be relatively stable.
* how to do might change, but the change constrain within the service, the hierarchy doesn't be impacted.

### 2.2.3 Defining services by applying the Decompose by sub-domain pattern

* centered on the development of an object-oriented domain model.
* Domain driven design (DDD)
* subdomains : same as business-capability
* bounded contexts: the scope of a domain model

* comparison:
* legacy: one big class across application, all business entity bound in one class
* DDD:
* separate domain model for each subdomain
* same as business-capability: analyze the business and identify the different areas of expertise


### 2.2.4 Decomposition guidelines

#### SINGLE RESPONSIBILITY PRINCIPLE: A class should have only one reason to change with only one responsibility
reduce the size of the services and increase their stability.

#### COMMON CLOSURE PRINCIPLE
* **open for extension**: This can often be achieved through techniques such as inheritance, interfaces, or composition. By creating new classes or modules to extend the system, you can introduce new features without affecting the existing code.
* **closed for Modification**: once a class or module is designed and implemented, it should not be modified to add new functionality.

### 2.2.5 Obstacles to decomposing an application into services

a. Network latency
b. Reduced availability due to synchronous communication
c. Maintaining data consistency across services
d. Obtaining a consistent view of the data
e. God classes preventing decomposition

#### NETWORK LATENCY:
* **scenario**: a large number of round-trips between two services
* **solution**:
* merge service from IPC to function call
* batch API

#### SYNCHRONOUS INTERPROCESS COMMUNICATION REDUCES AVAILABILITY
* **scenario**: won’t be able to create an order if any of those other services are unavailable, reduce availability
* **solution**:
* asynchrous message

#### MAINTAINING DATA CONSISTENCY ACROSS SERVICES
* **scenario**: Both of these updates must be done atomically across services, with two-phase, commit-based, distributed transaction management mechanism would lead to blocking issue.
* **solution**:
* eventually consistent- SAGA
ps.if atomic is required, this action should reside within a single service

#### OBTAINING A CONSISTENT VIEW OF THE DATA
* **scenario**: the inability to obtain a truly consistent view of data across multiple databases
* **solution**:
* quorum(?)
* rarely a problem
#### GOD CLASSES PREVENT DECOMPOSITION
* **scenario**: A god class typically implements business logic for many different aspects of the application. It normally has a large number of fields mapped to a database table with many columns, which leads to each services coupling together.
* **solution**:
* devide by DDD and build each services its own DB, data consistency with SAGA


### 2.2.6 Defining service APIs

service API exists for 2 type:
1. external client call
2. services collaboration call

* CH4. how SAGA support data consistency across services
* CH7. events function
* 1.how event support CQRS, support efficient querying
* 2.notify external client ex.websocket to browser

#### ASSIGNING SYSTEM OPERATIONS TO SERVICES
有必要資源的service處理對應的system operation

#### DETERMINING THE APIS REQUIRED TO SUPPORT COLLABORATION BETWEEN SERVICES

CH3 async/sync IPC

implement self-contained service by CQRS pattern (ch7) and SAGA (ch4)

SAGA by async message(api base?)

gateway(ch8) route the request by API composition pattern(ch7) rather than directly to services -> the system operation is assigned to the
API gateway rather than a service. The services need to implement the query operations needed by the API gateway.

### Summary

* determines maintainability,testability, and deployability, which directly impact development velocity.
* The microservice architecture is an architecture style that gives an application high maintainability, testability, and deployability.

* microservice architecture are organized around business concerns— business capabilities or subdomains—rather than technical concerns. (what services can do rather than how)
* decomposition pattern
* business capability- from scenario to assign the operation
* subdomain- DDD from domain model to decompose to services