Decomposite patterns Flashcards
Decomposition patterns
Decompose by business capability
Decompose by subdomain
Decompose by business capability: context
You are developing a large, complex application and want to use the microservice architecture.
Decompose by business capability: problem
How to decompose an application into services?
Decompose by business capability: forces
The architecture must be stable
Services must be cohesive
Services must conform to the Common Closure Principle
Services must be loosely coupled
A service should be testable
Each service be small enough to be developed by a “two pizza” team
Each team that owns one or more services must be autonomous.
Decompose by business capability: solution
Define services corresponding to business capabilities.
* It is something that a business does in order to generate value
A business capability often corresponds to a business object, e.g.
Business capabilities are often organized into a multi-level hierarchy. For example, an enterprise application might have top-level categories such as Product/Service development, Product/Service delivery, Demand generation, etc.
Decompose by business capability: example
The business capabilities of an online store include: * Product catalog management * Inventory management * Order management * Delivery management …
Decompose by business capability: result
Stable architecture since the business capabilities are relatively stable
Development teams are cross-functional, autonomous, and organized around delivering business value rather than technical features
Services are cohesive and loosely coupled
Decompose by business capability: issues
How to identify business capabilities?
Good starting points for identifying business capabilities are:
organization structure - different groups within an organization might correspond to business capabilities or business capability groups.
high-level domain model - business capabilities often correspond to domain objects
Decompose by business capability: related patterns
The Decompose by subdomain pattern is an alternative pattern
Decompose by business subdomain: context
You are developing a large, complex application and want to use the microservice architecture.
Decompose by business subdomain: problem
How to decompose an application into services?
Decompose by business subdomain: forces
The architecture must be stable
Services must be cohesive
Services must conform to the Common Closure Principle
Services must be loosely coupled
A service should be testable
Each service be small enough to be developed by a “two pizza” team
Each team that owns one or more services must be autonomous.
Decompose by business subdomain: solution
Define services corresponding to Domain-Driven Design (DDD) subdomains.
Each subdomain corresponds to a different part of the business.
Subdomains can be classified as follows:
* Core - key differentiator for the business and the most valuable part of the application
* Supporting - related to what the business does but not a differentiator. These can be implemented in-house or outsourced.
* Generic - not specific to the business and are ideally implemented using off the shelf software
Decompose by business subdomain: example
The subdomains of an online store include:
- Product catalog
- Inventory management
- Order management
- Delivery management
- …
Decompose by business subdomain: result
Stable architecture since the business capabilities are relatively stable
Development teams are cross-functional, autonomous, and organized around delivering business value rather than technical features
Services are cohesive and loosely coupled