Problem
How to decompose an application into subdomains?
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 affects 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
For the "God Classes" issue, DDD (Domain-Driven Design) comes to the rescue. It uses subdomains and bounded context concepts to solve this problem. DDD breaks the whole domain model created for the enterprise into subdomains.
Each subdomain will have a model, and the scope of that model will be called the bounded context. Each microservice will be developed around the bounded context.
Note: Identifying subdomains is not an easy task. It requires an understanding of the business.
Like business capabilities, subdomains are identified by analyzing the business and its organizational structure and identifying the different areas of expertise.
The following illustration shows how an insurance monolith is decomposed into subdomains after it was decomposed by business capabilities.
There are the following issues to address:
-
How to identify the subdomains? Identifying subdomains and hence services requires an understanding of the business. Like business capabilities, subdomains are identified by analyzing the business and its organizational structure and identifying the different areas of expertise. Subdomains are best identified using an iterative process. Good starting points for identifying subdomains are:
- organization structure - different groups within an organization might correspond to subdomains
- high-level domain model - subdomains often have a key domain object
