Storefront, API, Catalog, Cart, Checkout, and Order Boundaries

Goal

Explain how the main commerce boundaries divide customer-facing presentation, contract handling, business state, and order truth.

The customer does not experience a "catalog service" or an "order database." The customer sees a storefront, clicks through a set of screens, and expects the business to keep the promise that those screens imply. The architecture has to separate that visible experience from the business responsibilities underneath it.

The durable idea is:

A commerce platform stays understandable when the storefront, API, catalog, cart, checkout, and order each own a different job.

The Short Version

The storefront is the face of the system. It presents products, cart state, promotions, and checkout flows. It should not be the place where business truth lives.

The API boundary shapes contracts. It protects the backend from every consumer calling it directly, applies policies, and makes the public entry points easier to govern.

The catalog owns product truth. The cart owns shopper intent. Checkout owns the act of validating and accepting the order. The order boundary owns the record the business keeps after acceptance.

If those jobs blur together, the platform becomes difficult to change. If they stay distinct, the team can evolve one part without making the whole system brittle.

Boundary Map

Think of the flow like this:

Storefront
  -> API boundary
  -> Catalog / Cart / Checkout
  -> Order truth
  -> Downstream fulfillment work

Each boundary answers a different question.

Boundary	Main Job	Should Not Own
Storefront	Render the user experience and collect user input.	Order truth, payment state, or fulfillment logic.
API boundary	Publish contracts, policies, and routing rules.	Business decisions that belong to commerce capabilities.
Catalog	Describe products, prices, and discoverability.	Shopper intent or final order acceptance.
Cart	Preserve the customer's intent and current selections.	Long-lived business records or fulfillment state.
Checkout	Validate whether the business can accept the order.	Marketing pages, browsing logic, or warehouse execution.
Order	Keep the durable record of what was accepted.	Session state or presentation concerns.

This is a practical boundary model, not a rigid taxonomy. A company may split or combine these responsibilities in different ways, but the responsibilities themselves still exist.

Why the Boundaries Matter

The storefront is usually optimized for experience, not permanence. It can cache, render, and guide the shopper, but it should not become the only place the company knows what was ordered.

The API boundary matters because commerce is rarely consumed by just one front end. Web, mobile, partner, and support experiences all need controlled access. When the API boundary is clear, the business can change the storefront without forcing every consumer to relearn backend details.

The catalog, cart, checkout, and order responsibilities matter because they do not fail the same way.

A catalog issue may affect discovery and conversion.
A cart issue may make a shopper lose intent.
A checkout issue may prevent revenue or create duplicate orders.
An order issue may damage support, fulfillment, and accounting.

Those are different risks. The architecture should show that difference.

Example: Cart Versus Order

A shopper adds a pair of shoes to the cart, changes the size, and applies a coupon code. That work belongs to the cart and checkout flow because it is still shopper intent and validation.

Once the customer submits the order, the business needs a durable order record. The order record must preserve what was accepted even if pricing, inventory, or fulfillment systems continue working afterward.

That is why the cart and order cannot be treated as the same object. The cart can change. The order must be a durable statement of what the business accepted.

Common Mistakes

Letting the storefront own business rules.
Making the catalog the same thing as checkout.
Storing order truth in the same place as session state.
Exposing backend services directly to every consumer.
Using one boundary for every commerce concern because it feels simpler at the beginning.

If Someone Asks You

Why is it useful to separate storefront, catalog, cart, checkout, and order boundaries?

A good answer is:

Because each boundary has a different job. The storefront presents the experience, the API boundary governs access, the catalog describes products, the cart preserves intent, checkout validates acceptance, and the order keeps durable business truth. When those jobs stay separate, the platform is easier to explain, secure, and change.

What to Remember

The screen the customer sees is not the same thing as the business truth the company keeps.

Questions to Check Understanding

What belongs in the storefront?
What belongs in the order boundary?
Why is the API boundary valuable even when the storefront already exists?