Step 1 of DDD in Action: A Preferred Store Case Study Shows How to Apply Strategic Design

Business Goal and Scope

The system aims to increase order conversion, improve promotion configuration efficiency, reduce oversell and fulfillment errors, and guarantee accurate payment‑order reconciliation.

Sub‑Domain Identification

Store : store information, business hours, service area.

Catalog : SPU/SKU, categories, on/off‑shelf, product data.

Inventory : available stock, locked stock, stock release.

Promotion : coupons, discounts, activity rules.

Order Transaction : order creation, pre‑payment order, cancellation, refund entry.

Payment : initiate payment, handle payment callbacks, refund callbacks.

Fulfillment : preparation, self‑pickup, delivery, receipt.

Member : membership level, points, benefits.

Notification : SMS, in‑app messages, template messages.

Reconciliation : order, payment, refund, settlement verification.

Core‑Domain Determination

Order Transaction – core: directly affects transaction closure; model finely and protect rules.

Promotion – core: impacts conversion and changes frequently; model finely with extensible rules.

Inventory – key supporting: not a competitive edge but critical for correctness; clear boundaries, model key rules.

Fulfillment – key supporting: influences experience and store efficiency; model progressively based on complexity.

Catalog – supporting: provides product data; keep clear, avoid a universal model.

Store – supporting: provides basic store data; stable enough.

Member – supporting / potential core: may become core if growth relies on membership; start as supporting, upgrade later.

Payment – generic: mostly third‑party, use an anti‑corruption layer; do not re‑implement the channel.

Notification – generic: highly standardized; buy service, adapt only.

Reconciliation – generic (critical): financial accuracy required; keep stable, traceable, auditable.

Bounded Context Definition

Store Context – manages store data, hours, service area.

Catalog Context – manages product data, categories, SKU, on/off‑shelf.

Inventory Context – manages available, locked, and released stock.

Promotion Context – manages coupons, discounts, activity rules.

Order Context – creates orders, maintains status, records transaction snapshots.

Payment Context – adapts third‑party payment, handles callbacks.

Fulfillment Context – manages preparation, self‑pickup, delivery, receipt.

Member Context – manages membership level, points, benefits.

Notification Context – manages message templates and sending.

Reconciliation Context – verifies order, payment, refund, settlement data.

Each context has a boundary sentence, e.g.:

Order Context is responsible for creating orders, maintaining order state, and recording transaction snapshots; it does not manage product data or directly handle inventory quantities.

Unified Language

Key terms are disambiguated per context.

Product

Catalog: displayable product data and SKU ( Product, Sku).

Inventory: SKU stock item ( StockItem).

Order: snapshot of the product at order time ( OrderItem).

Promotion: item used in promotion calculation ( PromotionItem).

Price terms

List Price (Catalog) – base price shown to customers.

Promotional Price (Promotion) – price after applying promotion rules.

Transaction Price (Order) – price snapshot at order creation.

Paid Amount (Payment) – amount sent to the payment channel.

Reconciliation Amount (Reconciliation) – amount used for financial verification.

Event Storming (Lightweight)

ProductSnapshotConfirmed

– Order / Catalog (order needs a product snapshot, source is Catalog). StockValidated / StockLocked – Inventory (stock language belongs to Inventory). PromotionCalculated – Promotion (price rules belong to Promotion). OrderCreated / OrderPaid – Order (order state belongs to Order language). PaymentInitiated – Payment (payment interactions belong to Payment language). FulfillmentTaskCreated – Fulfillment (preparation, pickup, delivery belong to Fulfillment). PointsCredited – Member (points are a member benefit).

Stock and promotion must be synchronous with order; notification, points, and fulfillment can be asynchronous.

Context Mapping

Order → Catalog : fetch product snapshot (client‑server, synchronous query).

Order → Inventory : lock stock at order time (client‑server, synchronous call).

Order → Promotion : calculate and redeem promotion (client‑server, synchronous call).

Order → Payment : initiate payment (anti‑corruption layer, synchronous call).

Payment → Order : notify payment success/failure (publish language, callback + event).

Order → Fulfillment : create fulfillment task after payment (domain event, asynchronous subscription).

Order → Member : credit points after payment (domain event, asynchronous subscription).

Order → Notification : send status change notifications (domain event, asynchronous subscription).

Order / Payment → Reconciliation : aggregate data for accounting (publish language, async batch).

Quality Attributes and Risks

Consistency : order amount, payment amount, and stock must not conflict – achieved by synchronous confirmation of price and stock, and payment callback driving order state.

Availability : slow downstream services (notification, points, fulfillment) must not block payment success – handled by asynchronous post‑payment actions.

Traceability : when price errors, oversell, or reconciliation mismatches occur, the source must be identifiable – order stores a snapshot; payment and reconciliation keep immutable logs.

Evolvability : promotion and membership rules change frequently – separate contexts with clear contracts.

Isolation : third‑party SDKs (payment, SMS, delivery) must not pollute domain models – all external interactions go through anti‑corruption layers.

Key Architectural Decisions (Simplified ADR)

Do not split into micro‑services in the first phase; start with a modular monolith to reduce distributed complexity.

Synchronously lock inventory during order creation to avoid oversell, accepting extra latency.

Handle post‑payment actions (notification, points, fulfillment) via asynchronous events to keep the main flow stable.

Never embed payment channel logic inside the order model; always use an anti‑corruption layer.

Persist product and price snapshots in the order for historical correctness, even though it increases storage.

Open Questions

When should a coupon be released after payment timeout – immediately or delayed?

How long should locked stock be auto‑released?

How to handle self‑pickup timeout orders?

Is partial refund allowed?

Should member points be granted after payment success or after order completion?

Review Checklist

Do we clearly know which domains are core?

Do we know which are supporting or generic?

Does each bounded context have a clear "responsible / not responsible" sentence?

Are terms like "product", "price", "stock" disambiguated across contexts?

Are synchronous vs. asynchronous paths in the order flow explicit?

Are all external systems isolated by anti‑corruption layers?

Can critical risks be traced, compensated, and reviewed?

Have all uncertain business rules been listed as open questions?

Strategic Design Deliverables

Business Goal : increase order conversion, ensure price, stock, fulfillment, and financial accuracy.

Sub‑Domain Map : Store, Catalog, Inventory, Promotion, Order, Payment, Fulfillment, Member, Notification, Reconciliation.

Core‑Domain Decision : Order Transaction and Promotion are core; Inventory and Fulfillment are key supporting.

Bounded‑Context List : Store, Catalog, Inventory, Promotion, Order, Payment, Fulfillment, Member, Notification, Reconciliation.

Unified Language Table : key terms clarified per context (product, price, stock, order status, coupon, payment order, etc.).

Context‑Mapping Diagram : shows synchronous order path and asynchronous post‑payment collaborations.

Risk List : oversell, price mismatch, duplicate coupon usage, lost payment callbacks, fulfillment delay, reconciliation inconsistency.

Next Step – Tactical Design

After the strategic phase, tactical design starts with the most critical core domain (e.g., Order). Typical questions include the aggregate boundary of Order, whether OrderItem is an entity or value object, how price and product snapshots are modeled, how inventory and promotion collaborate during order creation, who owns order‑state transitions, when to emit OrderPlacedEvent, and the persistence strategy for aggregates.