DDD Scoping Deliverables Examples — Order Placement

This article showcases concrete deliverables generated during the domain discovery and modeling phase for our e-commerce order placement application.

🟧 1. EventStorming (Domain Timeline of Business Events)

An EventStorming workshop brings domain experts, product managers, and developers into the same room. Together, they map out past domain events (orange 🟧), triggering user commands (blue 🟦), aggregates / entities (yellow 🟨), and business rules or policies (purple 🟪) along a chronological axis.

Workshop Concrete Output:

[👤 Customer] 
   │
   ▼
🟦 [PlaceItemInCart] ──▶ 🟨 Cart ──▶ 🟧 [ItemAddedToCart]
                                            │
                                            ▼ (Rule: Check immediate stock)
                                       🟪 [If insufficient stock ➔ Show alert]
                                            │
   ┌────────────────────────────────────────┘
   ▼
🟦 [AuthorizePayment] ──▶ 🟨 Payment ──▶ 🟧 [PaymentAuthorized]
                                            │
                                            ▼ (Policy: Upon successful payment)
                                       🟪 [Trigger order confirmation]
                                            │
   ┌────────────────────────────────────────┘
   ▼
🟦 [CreateOrder] ──▶ 🟨 Order ──▶ 🟧 [OrderConfirmed]
                                            │
                                            ├──▶ 🟧 [StockPermanentlyReserved]
                                            └──▶ 🟧 [ShippingDispatchRequested]

Key Takeaway: Within a few focused hours, the entire team builds a shared mental model and identifies 4 distinct bounded contexts without ambiguity: Catalog, Cart, Payment, and Order.

🗺️ 2. Bounded Context Canvas (Domain Identity Sheet)

The Canvas summarizes the core responsibilities, strategic boundaries, and ubiquitous language of a single bounded context. Here is the concrete canvas for the Order Context:

📋 Context Canvas: Order Domain (Order Context)

Primary Responsibility: Embody the immutable commercial contract, govern the order lifecycle, and coordinate logistics and invoice issuance.
Ubiquitous Language (Glossary):
- Order: Root aggregate entity, strictly immutable once confirmed.
- OrderLine: Snapshot value object (name, product SKU, unit price locked in at time of purchase).
- OrderStatus: Discrete strict state machine (CREATED, PAID, PREPARING, SHIPPED, DELIVERED, CANCELLED).
- Invoice: Associated legal tax and accounting record.
Critical Invariants & Business Rules:
- An order cannot transition to the PAID state without a verified transaction token from the Payment domain.
- An order's total amount can never be recalculated or altered after confirmation.
Domain Relationships (Context Map):
- Cart (Upstream / Supplier): Consumes CartCheckedOut event containing validated item lines.
- Payment (Upstream / Partner): Synchronous or asynchronous dependency on PaymentAuthorized.
- Logistics & Shipping (Downstream / Customer): Emits OrderReadyForDispatch event.

🥒 3. Concrete Examples & BDD (Gherkin Scenarios)

Given / When / Then scenarios formalize business rules into executable specifications understood by business stakeholders and directly automated into acceptance tests (Cucumber, Behave, Playwright, Jest).

Feature: Order validation and stock reservation

  Background:
    Given a product "Studio Headphones Pro" priced at $199 with 3 units in stock
    And an authenticated customer "Alice" with an active cart containing 1 "Studio Headphones Pro"

  Scenario: Successful order with available inventory and verified payment
    When Alice pays for her cart of $199 with a valid credit card
    Then the payment is approved with transaction ID "TX-9876"
    And an order "CMD-001" is created in "PAID" state
    And remaining stock for "Studio Headphones Pro" is decremented to 2 units
    And a shipping notification is dispatched to the logistics center

  Scenario: Order failure upon card decline (Zero ghost orders)
    When Alice attempts to pay for her cart with an expired card
    Then the payment gateway declines the transaction with reason "INSUFFICIENT_FUNDS"
    And no order is created in the system
    And the stock for "Studio Headphones Pro" remains unchanged at 3 units
    And Alice's cart remains intact and available for retry

📐 4. C4 Container Diagrams & Diagrams-as-Code

Rather than static diagrams trapped in presentation decks, the system architecture is maintained as versioned, auditable text code right next to the application source code.

Container Diagram (C4 Level 2):

← Back to Application Architecture | Go to Infrastructure Implementation →