Please enable JavaScript.
Coggle requires JavaScript to display documents.
Identify Bounded Contexts in Microservices, Identify Bounded Contexts in E…
Identify Bounded Contexts in Microservices
Understand Business Domain
Interview domain experts
Map user journeys
Document key terminology
Identify Core Business Capabilities
List main functions
Group related features
Spot natural business separations
Analyze Ubiquitous Language
Detect different meanings for same term
Establish language boundaries
Map Entity Relationships
Draw ERDs per business area
Find clusters of related entities
Identify differently-modeled shared entities
Data Ownership
Who owns which data?
Avoid shared databases
Map data flow between areas
Analyze Business Processes
Map process flows
Identify handoff points and responsibility shifts
Note differing rules per step
Organization & Teams
Conway’s Law (team structure = system structure)
Team-to-context alignment
Integration Points
APIs, events, anti-corruption layers (ACL)
Identify translation/mapping needs
Change Rates & Autonomy
Find fast-changing modules
Note team autonomy needs
Isolate rapidly-changing contexts
Validate & Document
Stakeholder review and feedback
Draw context map
Document integration contracts and boundaries
Identify Bounded Contexts in E-commerce Microservices
Understand Business Domain
Interview product managers and business experts
Map user journeys (browsing, ordering, returns)
Document terms: Product, Order, Customer, Payment, Inventory, Shipping
Identify Core Business Capabilities
Product Catalog Management
Manage products, categories, inventory
Order Management
Place, track, and update orders
Customer Management
Profiles, addresses, loyalty
Payment Processing
Payment, refunds, invoices
Shipping & Delivery
Fulfillment, shipment tracking
Promotions & Discounts
Coupons, campaigns, loyalty rewards
Support & Returns
Customer tickets, returns, complaints
Analyze Ubiquitous Language
"Order" means customer purchase in Order Management
"Order" could mean fulfillment request in Shipping
"Product" in Catalog context is rich in details, in Order context may be simplified
"Customer" profile differs for Support vs. Marketing
Map Entity Relationships
Product Catalog: Product, Category, Inventory
Order Management: Order, OrderLine, Payment, Shipment
Customer Management: Customer, Address, LoyaltyPoints
Support: Ticket, Customer, Order, Product
Data Ownership
Product owned by Catalog Service
Order owned by Order Service
Payment owned by Payment Service
Customer owned by Customer Service
Avoid shared tables across services
Analyze Business Processes
Product Discovery: Catalog, Search, Recommendation
Checkout: Cart, Order, Payment, Inventory
Fulfillment: Order, Shipping, Delivery
Returns: Order, Ticket, Refund
Organization & Teams
Teams aligned with business functions (Catalog, Orders, Payments, Shipping, Support)
Team boundaries = context boundaries (Conway's Law)
Integration Points
Catalog Service exposes products to Order Service
Order Service calls Payment Service for payment processing
Order Service notifies Shipping Service when order is ready to ship
Customer Service provides customer data to Support Service
Integration via REST APIs, events, or message queues
Change Rates & Autonomy
Promotions and Campaigns change frequently, should be separate
Order and Payment services may have different release cycles
Teams need autonomy to deploy and scale independently
Validate & Document
Review bounded contexts with stakeholders
Draw context map of services and their relationships
Document integration contracts, APIs, and event schemas
Interview product managers and business experts
Who
Product managers
Business owners
Sales leads
Support reps
Tech leads
Customers (for feedback)
What
Business processes
Pain points and challenges
Business goals and KPIs
Workflow steps
Domain terminology
Product/service expectations
When
At project kickoff
Before system design
When requirements change
During retrospectives or reviews
Where
Workshops
One-on-one interviews
Team meetings (in-person or remote)
Focus groups
Online surveys or forms
Why
To understand business needs and priorities
To clarify domain concepts and workflow
To prevent miscommunication between business and tech
To ensure the system fits real business scenarios
How
Prepare scenario-based questions
Use event storming or domain modeling workshops
Record and summarize findings for the whole team
Map findings to business capabilities and context boundaries