Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Full FlowZap Code
Frontend { # Frontend BFF
n1: circle label:"User Action"
n2: rectangle label:"BFF Layer"
n3: rectangle label:"Compose UI Response"
n4: circle label:"Render UI"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Identity.n5.handle(top) [label="Auth Check"]
n3.handle(right) -> n4.handle(left)
}
Identity { # Identity & Access
n5: rectangle label:"Authenticate User"
n6: diamond label:"Authorized?"
n7: rectangle label:"Issue Access Token"
n8: rectangle label:"Deny Access"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Yes"]
n6.handle(bottom) -> n8.handle(top) [label="No"]
n7.handle(bottom) -> Catalog.n9.handle(top) [label="Token"]
n8.handle(top) -> Frontend.n3.handle(bottom) [label="403"]
}
Catalog { # Product Catalog
n9: rectangle label:"Fetch Product Details"
n10: rectangle label:"Product Database"
n11: rectangle label:"Return Catalog Data"
n9.handle(right) -> n10.handle(left) [label="Query"]
n10.handle(right) -> n11.handle(left) [label="Products"]
n11.handle(bottom) -> Pricing.n12.handle(top) [label="Product IDs"]
n11.handle(top) -> Frontend.n3.handle(bottom) [label="Catalog JSON"]
}
Pricing { # Pricing & Promotions
n12: rectangle label:"Calculate Price"
n13: rectangle label:"Apply Promotions"
n14: rectangle label:"Return Final Price"
n12.handle(right) -> n13.handle(left) [label="Base Price"]
n13.handle(right) -> n14.handle(left) [label="Discounted"]
n14.handle(top) -> Frontend.n3.handle(bottom) [label="Price JSON"]
}
Fulfillment { # Order Fulfillment
n15: rectangle label:"Reserve Inventory"
n16: rectangle label:"Create Shipment"
n17: rectangle label:"Update Order Status"
n15.handle(right) -> n16.handle(left) [label="Reserved"]
n16.handle(right) -> n17.handle(left) [label="Shipped"]
n17.handle(top) -> Frontend.n3.handle(bottom) [label="Status Update"]
}
Why This Workflow?
Decomposing a monolith by technical layers (UI, business logic, data) leads to distributed monoliths where every change requires coordinating multiple teams. Decomposition by business capability aligns service boundaries with organizational structure, enabling autonomous teams that own the full stack for their domain.
How It Works
- Step 1: Business capabilities are identified: Identity, Product Catalog, Pricing, and Fulfillment.
- Step 2: Each capability becomes an independent microservice with its own API and data store.
- Step 3: A Backend-for-Frontend layer aggregates data for specific client platforms.
- Step 4: The Identity service authenticates users and issues access tokens.
- Step 5: Product Catalog and Pricing services operate independently but share product IDs.
- Step 6: The Fulfillment service handles inventory reservation and shipment creation.
Alternatives
Decomposition by subdomain (DDD) is more rigorous but requires domain expertise. Decomposition by technical layer is simpler but creates coupling. This template provides a practical starting point for teams planning their first microservices decomposition.
Key Facts
| Template Name | Microservices Decomposition by Business Capability |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration.
Architecture
A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.