Case Study on Decomposing an E-Commerce Platform

An e-commerce platform is one of the best decomposition case studies because it contains several capabilities that are clearly related but not identical: catalog, checkout, billing, inventory, fulfillment, notifications, and reporting. It also contains many opportunities to make bad boundary choices. Teams often over-centralize around one huge order service, or they over-fragment into entity-based services that chat constantly. The interesting work is not naming the services. It is deciding which responsibilities truly belong together and which interactions should stay synchronous, become asynchronous, or move into read models.

This case study shows one plausible evolution rather than one universal answer.

    flowchart LR
	    C["Catalog"] --> CH["Checkout"]
	    CH --> B["Billing"]
	    CH --> I["Inventory"]
	    CH --> F["Fulfillment"]
	    C --> R["Search and reporting read models"]
	    B --> R
	    I --> R
	    F --> R

What to notice:

• checkout is important but not the owner of every downstream concern
• reporting and search are derived consumers rather than primary sources of truth
• the boundaries are chosen around business capabilities, not only around tables

The Common Starting Mistakes

Many teams begin in one of two unhealthy ways:

• one overloaded order service owns ordering, payment status, inventory status, shipment status, and customer notifications
• many entity-based services split order, order line, address, payment method, and customer profile into thin APIs

The first approach centralizes too much workflow and domain meaning into one service. The second spreads one business workflow across too many low-value boundaries. Both create coordination pain, just in different shapes.

A Healthier Decomposition

A stronger architecture usually treats these as distinct concerns:

• catalog owns browseable product information
• checkout owns user-facing order flow and immediate workflow state
• billing owns payment and invoice logic
• inventory owns stock reservation and availability truth
• fulfillment owns shipment preparation and delivery state

Notification and reporting concerns often become:

• supporting utilities
• or derived consumers through events and read models

This keeps the core domain services closer to business meaning.

Workflow Choices Matter as Much as Service Names

The main user-facing flow often needs:

• synchronous billing authorization
• synchronous inventory reservation
• asynchronous reporting and notification updates

That mix matters. If the team makes everything synchronous, the checkout path becomes fragile. If it makes every step asynchronous without clear states, the user experience becomes ambiguous.

A Sample Review Record

 1ecommerce_boundary_review:
 2  catalog:
 3    role: browse_and_discovery
 4    source_of_truth: product_data
 5  checkout:
 6    role: customer_facing_order_flow
 7    source_of_truth: order_workflow_state
 8  billing:
 9    role: payment_and_invoice_logic
10    source_of_truth: payment_state
11  inventory:
12    role: stock_and_reservation_state
13    source_of_truth: availability
14  fulfillment:
15    role: shipment_execution
16    source_of_truth: delivery_progress

What this demonstrates:

• each boundary has a clear responsibility and source of truth
• checkout coordinates the user-facing flow without owning every downstream domain
• the review is capability-centered rather than entity-centered

Where Teams Commonly Regress

Even after a good first design, the system often regresses through:

• reporting needs that bypass domain APIs
• convenience fields added to checkout until it starts re-owning other domains
• inventory or billing logic copied into experience layers
• notifications turning into a shadow workflow service

This is why decomposition is not finished once the first diagram is drawn.

Design Review Question

A team says checkout should own payment, inventory, and fulfillment status permanently because “that is the customer journey.” What is the stronger challenge?

The stronger challenge is that customer journey ownership does not automatically equal domain ownership. Checkout should present and coordinate the user-facing flow, but if it becomes the authoritative owner of payment, inventory, and shipment logic too, the architecture is likely recreating one centralized workflow monolith under a more modern name.

Quiz Time