- Microservices Design Patterns Tutorial
- Microservices Design Patterns - Home
- Microservices Design Patterns - Overview
- Decomposition Design Patterns
- Decompose by Business Capability
- Decompose by Subdomain
- Decompose by Strangler
- Integration Design Patterns
- API Gateway
- Aggregator
- Proxy
- Client Side UI Composition
- Chain Of Responsibilities
- Branch
- Database Design Patterns
- Database per Service
- Shared Database per Service
- Command Query Responsibility Segregator
- Saga
- Aysynchronous Messaging
- Event Sourcing
- Observability Design Patterns
- Log Aggregation
- Performance Metrics
- Distributed Tracing
- Health Check
- Cross Cutting Concern Design Patterns
- External Configuration
- Service Discovery
- Circuit Breaker
- Blue Green Deployment
- Useful Resources
- Quick Guide
- Useful Resources
- Discussion
Decompose By Business Capability
Problem Statement
Microservice architecture structures an application as a set of loosely coupled microservices and each service should be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, the major problem is how to design loosely coupled microservices or to break a large application into small loosely coupled services?
Solution
We can define a microservice corresponding to a particular business capability. A business capability refers to the business activity targetted to generate value. A business capability can be referred as business object. For Example −
Order Management − Order Management Business Capability refers to Orders.
Customer Management − Customer Management Business Capability refers to Customers.
Business Capabilities can further be categorized into multi-level hiearchical structure. For example, Order Mangement can have delivery, inventory, service etc. as business capabilities.
Example
Consider an example of an Online Book Store. It can have following business capabilities and corresponding microservices −
Books Catalog Management
Inventory Management
Order Management
Warranty Management
Advantages
Stable Architecture − As business capabilities are stable, this architecture is highly stable.
Cross-functional Teams − Development Teams works independently, are cross-functional and are organized around functional features instead of technical features.
Loosely Coupled Services − Developed services will be loosely coupled and cohesive.
Dis-advantages
Need good understand of Business − Business capabilities needs be indentified after understanding the business. Understanding organizational structure can help as organizations are structured based on their capabilities.
High Level Domain Model needed − Business domain objects required as they corresponds to business capabilities.
