Reference
3 steps:
- Identify system operations
- Identify services
- Define services APIs and collaborations
Step1: Identifying system operations
- Create a high level domain model
- Define system operations
Step 2: Identity services
- Define services corresponding to business capabilities
- Organize services around domain-driven design subdomains
- Organize services around business concepts rather than technical concepts
Defining services by applying the Decompose by sub-domain pattern
Decomposition guidelines
- SINGLE RESPONSIBILITY PRINCIPLE: A class should have only one reason to change
- COMMON CLOSURE PRINCIPLE: The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package. ( We can apply CCP when creating a microservice architecture and package components that change for the same reason into the same service.)
Obstacles to decomposing an application into services
- Network latency
- Reduced availability due to synchronous communication
- Maintaining data consistency across services
- Obtaining a consistent view of the data
- God classes preventing decomposition
God classes
" 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. Most applications have at least one of these classes, each representing a concept that’s central to the domain: accounts in banking, orders in e-commerce, policies in insurance, and so on. "
Defining service APIs
A service API operation exists for one of two reasons:
- some operations correspond to system operations. They are invoked by external clients and perhaps by other services.
- The other operations exist to support collaboration between services. These operations are only invoked by other services.
- ASSIGNING SYSTEM OPERATIONS TO SERVICES
- DETERMINING THE APIS REQUIRED TO SUPPORT COLLABORATION BETWEEN SERVICES
沒有留言:
張貼留言