Problem
How to decompose an application into services?
Forces
- The architecture must be stable
- Services must be cohesive. A service should implement a small set of strongly related functions.
- Services must conform to the Common Closure Principle - things that change together should be packaged together - to ensure that each change affect only one service
- Services must be loosely coupled - each service as an API that encapsulates its implementation. The implementation can be changed without affecting the clients
- A service should be testable
- Each service be small enough to be developed by a “two-pizza” team, i.e. a team of 6-10 people
- Each team that owns one or more services must be autonomous. A team must be able to develop and deploy its services with minimal collaboration with other teams.
Solution
One strategy is to decompose by business capability. A business capability is something that a business does in order to generate value.
The set of capabilities for a given business depends on the type of business. For example, the capabilities of an insurance company typically include sales, marketing, underwriting, claims processing, billing, compliance, etc.
Each business capability can be thought of as a service, except it’s business-oriented rather than technical.
Issues
There are the following issues to address:
How to identify business capabilities? Identifying business capabilities and hence services requires an understanding of the business.
An organization’s business capabilities are identified by analyzing the organization’s purpose, structure, business processes, and areas of expertise. Bounded contexts are best identified using an iterative process.
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
