From Event Storming to Microservices: A Practical Guide to Bounded Context Splitting

What Is a Bounded Context?

A bounded context is a high-cohesion, low-coupling business closure boundary that defines the semantic boundary of domain terms. It has three core characteristics:

Internal high correlation: Aggregates are strongly bound by business, coherent processes, and transactional consistency.

External decoupling: Exposes unified capabilities without leaking internal domain model details.

Semantic independence: Each domain term has a single, unique meaning within the context.

Simple rule: aggregates that change together, flow together, and share data belong in the same context.

Common mistakes include splitting by database tables or functional modules (e.g., "User Service", "Product Service"), which violates DDD principles. A classic semantic conflict: "User" in a Member context means membership level, coupons, real-name info; in an Order context it means only shipping contact and phone. Merging them causes field bloat and logic pollution.

Four Golden Rules for Context Splitting

Rule 1: Transaction Consistency First

Aggregates that must succeed or fail together in a single business transaction must belong to the same context. Cross-context strong distributed transactions are discouraged; prefer domain events for eventual consistency. If many scenarios require cross-context strong transactions, the boundary is wrong.

Example: Order creation, status change, and order details are strongly transaction-bound — cannot split. Inventory lock/release forms its own closed loop — independent context.

Rule 2: Business Change Frequency

Aggregates that change at the same cadence merge into one context; those with independent, non-interfering iteration cycles split firmly.

Case: Marketing campaigns, coupons, and points often co-evolve — place in a single Marketing context. Do not split into Coupon Service, Points Service, Campaign Service.

Rule 3: Semantic Uniqueness

If the same noun carries different meanings in different business scenarios, split the context. When an entity appears in multiple domains, use an Anti-Corruption Layer (ACL) for data translation — never reuse the model directly.

Rule 4: Team Responsibility Boundary (Conway's Law)

A complete business domain owned by one team should converge into one context. Avoid frequent cross-team changes to the same domain to reduce collaboration overhead. System architecture mirrors organizational communication structure; do not design architectures beyond team collaboration capacity.

Hands-On: E-Commerce Case Study

Building on the previous article's event storming output for an e-commerce ordering flow, the identified aggregates were: Order, Inventory, Payment, Logistics.

Step 1: Aggregate Cohesion Validation

Order aggregate: owns order lifecycle only — self-contained.

Inventory aggregate: handles stock lock/release/pre-occupy — self-contained.

Payment aggregate: manages payment orders, refunds, reconciliation — self-contained.

Logistics aggregate: handles shipping, tracking, delivery confirmation — self-contained.

Step 2: Transaction & Flow Verification

Ordering chain: Order Created → Inventory Locked → Payment Generated → Payment Completed → Fulfillment Shipped.

The chain is linked but transactions are not nested:

Order failure does not affect inventory history.

Payment timeout rolls back only order and inventory, not logistics.

This satisfies low coupling and independent transactions.

Step 3: Final Standardized Split

Order Bounded Context: Order main flow, status, details.

Inventory Bounded Context: Stock lock, release, pre-occupy.

Payment Bounded Context: Payment orders, refunds, callbacks, reconciliation.

Logistics Bounded Context: Shipping fulfillment, tracking, delivery status.

Extension: Can Inventory and Product Catalog Merge?

Product base info (name, image, category) belongs to Product Catalog Context ; sellable quantity and pre-occupied stock belong to Inventory Context . They change at different frequencies — catalog is read-heavy, inventory write-heavy. Catalog queries needing stock levels should consume cached events, not synchronous calls.

Inter-Context Communication: Two Patterns

Pattern 1: Synchronous (RPC/HTTP)

Applicable for real-time queries and strong immediate-feedback scenarios. Drawbacks: creates service coupling, lengthens call chains, risks cascade failures. Rule: prohibit large-scale cross-context synchronous writes.

Pattern 2: Asynchronous Domain Events (Message Queue)

Applicable for business process orchestration, data sync, downstream fulfillment. Advantages: decouples contexts, absorbs traffic spikes, enables eventual consistency.

E-commerce standard practice:

Order creation publishes OrderCreated domain event.

Inventory service consumes event to lock stock.

Payment service consumes event to generate payment record.

Entire flow is async-driven, minimizing synchronous dependencies.

Four Common Pitfalls

Pitfall 1: Forcing Splits Just to Have More Services

Misconception: more microservices = better. Result: simple business split into 7-8 contexts, call chains longer than code, debugging nightmare. Correct: context granularity may lean slightly coarse; never over-fragment. SMEs should not blindly copy big-tech architectures built for massive scale and multi-team coordination.

Pitfall 2: Stuffing Generic Capabilities into Business Contexts

Dictionaries, configs, notifications, file uploads — do not shove into business domains. Extract into a Generic Support Context for global reuse.

Pitfall 3: Static Boundaries That Never Evolve

Business iterates continuously; architecture unchanged for six months. Initially sound boundaries inevitably couple as business grows. Correct: before major version iterations, re-run event storming and micro-adjust boundaries. DDD modeling is continuous evolution, not one-off work.

Pitfall 4: Equating Bounded Contexts 1:1 with Microservices

Bounded Context ≠ Microservice.

Large-scale, high-concurrency: one context → multiple microservices (read/write split, vertical split).

Small-to-medium: multiple lightweight contexts → merged into one deployable service.

This is the key to avoiding service explosion. Many small teams force one context = one service, causing ops cost to skyrocket.

Conflict Resolution: When Aggregate Ownership Is Ambiguous

Post-event-storming disputes: does an aggregate belong to Context A or B? Three decision frameworks:

Data Ownership: Which domain owns the primary data the aggregate operates on?

Trigger Origin: Which domain initiates the business flow involving this aggregate?

New Context: If bidirectional strong dependency exists, don't force assignment — extract an independent context.

Case: Shopping Cart aggregate depends on Product info, Inventory, and User — bidirectional dependencies. Do not place in Order or Product. Create independent Shopping Cart Context , sync required base data via events.

Mapping Contexts to Microservice Architecture

A practical mapping formula:

High concurrency, independent iteration, core business contexts → Independent microservices (e.g., Order, Payment, Inventory).

Low concurrency, auxiliary, rarely changing contexts → Merge into shared services (e.g., Messaging, Logging, Config, Notification).

Contexts expected to grow rapidly → Reserve independent service capability upfront.

Architect skill is trade-offs, not diagrams. No blind splitting, no forced merging — adapt dynamically to business volume, team size, concurrency profile.

Deliverables Checklist (Event Storming → Context Artifacts)

Modeling must leave the whiteboard as standardized docs for team consensus:

Domain Event Storming Master Diagram (commands, events, aggregates).

Bounded Context Division List with contained aggregates annotated.

Context Glossary (unified domain term definitions to eliminate ambiguity).

Context Interaction Diagram: synchronous calls and async event flows.

Boundary Conflict Log with Decision Rationale (preserve architectural trade-off records).

Many teams' modeling fails due to missing documentation — new hires cannot understand boundary rationale.

Summary (Team Architecture Standard)

Event storming produces aggregates; aggregate clustering produces bounded contexts.

Core splitting criteria: transaction consistency, change consistency, semantic independence, team division.

Avoid over-coarse, over-fine, and table-driven splits.

Context = business boundary; Microservice = deployment boundary; they are not forced 1:1.

Cross-context communication: prefer async domain events; strictly limit synchronous writes.

DDD modeling is continuous evolution — periodic boundary reviews on business iterations.

All chaotic microservice architectures trace back to initial context splitting errors.