Why Right-Sizing Microservices is Important
- Avoids monolith services that are too large or complex.
- Prevents over-segmentation into too many tiny microservices, causing communication overhead.
- Ensures microservices are easy to manage, scale, and deploy independently.
Domain-Driven Design (DDD) Sizing
Domain-Driven Design (DDD) is a strategic approach that helps break down systems into meaningful bounded contexts based on business logic.
Steps for DDD-based Microservice Sizing
- Identify Bounded Contexts: Break down your application into business subdomains (e.g., for an e-commerce system: Order Management, Product Catalog, and Payment).
- Define Aggregates: Within each bounded context, identify core entities (e.g., for Order Management: Orders, Customers, Payments).
- Encapsulate Business Logic: Implement business logic and enforce invariants within the bounded context.
- Use Ubiquitous Language: Ensure that all teams (developers, product managers, etc.) use the same terminology to avoid miscommunication.
Example of DDD in Microservice Sizing
Consider an e-commerce system with several subdomains: Product Catalog, Order Management, and Customer Support. Each subdomain is a candidate for a microservice. For instance:
- Product Catalog Service: Handles products, categories, pricing, and availability.
- Order Management Service: Manages customer orders, payments, and shipping.
- Customer Support Service: Deals with customer queries and complaints.
Pros of DDD-based Sizing
- Services align closely with business logic and domains.
- Encapsulation of business logic makes services more cohesive.
- Scales with large teams and complex systems, as different teams own different contexts.
Cons of DDD-based Sizing
- Requires a deep understanding of business domains, which may be time-consuming.
- Not suitable for small or less complex systems where the boundaries are unclear.
- Can lead to communication issues if the team doesn't properly define bounded contexts.
Challenges & Solutions
- Challenge: Defining clear boundaries between contexts can be tricky. Solution: Use continuous feedback from business stakeholders and iterate on context boundaries.
- Challenge: Over-compartmentalization of services can lead to complex integration. Solution: Keep bounded contexts reasonably sized and ensure proper communication between them.
Event Storming Sizing
Event Storming is a collaborative workshop technique where business events drive the discovery of service boundaries. The goal is to understand how the system behaves based on domain events.
Steps for Event Storming-based Microservice Sizing
- Gather Domain Events: Identify key domain events (e.g., "Order Placed", "Payment Processed").
- Collaborative Discovery: Gather business stakeholders, developers, and domain experts to map out these events and dependencies.
- Identify Aggregates: Group related events together under an aggregate or domain object.
- Define Service Boundaries: Define service boundaries around aggregates that process similar events.
Example of Event Storming Sizing
For an e-commerce system, domain events might include:
- "Product Added to Cart"
- "Order Placed"
- "Payment Processed"
Using Event Storming, you might group events such as "Order Placed" and "Payment Processed" together, forming the basis for an "Order Management" service. "Product Added to Cart" might belong to a "Shopping Cart" service.
Pros of Event Storming Sizing
- Involves all stakeholders in the design process, ensuring alignment with business requirements.
- Helps visualize complex systems in a simple, event-driven way.
- Encourages discussion and exploration of system behaviors.
Cons of Event Storming Sizing
- Workshops may be time-consuming and require extensive collaboration.
- May lead to over-segmentation if every event is turned into a service boundary.
- Relies heavily on capturing the correct domain events, which can be difficult in large systems.
Challenges & Solutions
- Challenge: Identifying all relevant events can be difficult, especially in complex domains. Solution: Start with high-level events and refine the details over multiple sessions.
- Challenge: Over-segmenting services based on too many domain events. Solution: Focus on core domain events and group related ones into cohesive services.
Conclusion: Choosing Between DDD and Event Storming
- Domain-Driven Design (DDD) works best when you have a good understanding of the business domains and want to model services around core business logic.
- Event Storming is ideal when you want a more interactive, collaborative approach to defining service boundaries and understanding system behavior through domain events.
- Both approaches are not mutually exclusive and can be combined depending on the complexity of the system and the clarity of the business logic.
Example of microservices for bank application
