- Discussion
- Useful Resources
- Quick Guide
- Blue Green Deployment
- Circuit Breaker
- Service Discovery
- External Configuration
- Health Check
- Distributed Tracing
- Performance Metrics
- Log Aggregation
- Event Sourcing
- Aysynchronous Messaging
- Saga
- Command Query Responsibility Segregator
- Shared Database per Service
- Database per Service
- Branch
- Chain Of Responsibilities
- Client Side UI Composition
- Proxy
- Aggregator
- API Gateway
- Decompose by Strangler
- Decompose by Subdomain
- Decompose by Business Capability
- Microservices Design Patterns - Overview
- Microservices Design Patterns - Home
Selected Reading
- Who is Who
- Computer Glossary
- HR Interview Questions
- Effective Resume Writing
- Questions and Answers
- UPSC IAS Exams Notes
Decompose By Subdomain
Problem Statement
Microservice architecture structures an apppcation as a set of loosely coupled microservices and each service should be developed independently in agile manner to enable continous depvery/deployment. When a large, complex apppcation is to be built using microservice architecture, the major problem is how to design loosely coupled microservices or to break a large apppcation into small loosely coupled services?
Solution
We can define a microservice corresponding to Domain-Driven Design(DDD) subdomains. DDD refers to business as a domain and a domain can have multiple subdomains. Now each subdomain refers to different areas. For Example −
Order Management − Order Management subdomain refers to Orders.
Customer Management − Customer Management subdomain refers to Customers.
Subdomains can be further classified using following criterias −
Core − Most important and key differentiator of an apppcation.
Supporting − Business related and are used to support the business activities.
Generic − Not specific to business but are used to enhance the business operations.
Example
Consider an example of an Onpne Book Store. It can have following subdomains and corresponding microservices −
Books Catalog Management
Inventory Management
Order Management
Warranty Management
Advantages
Stable Architecture − As business subdomains 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 subdomains needs be indentified after understanding the business. Understanding organizational structure can help as organizations are structured based on their capabipties.
High Level Domain Model needed − Business domain objects required as they corresponds to business subdomains.