Boundaries — Example: E-Commerce Platform

The Scenario

An online store where customers browse products, add items to a cart, check out with payment, receive order confirmations, and track shipment. Administrators manage the product catalog, adjust inventory, and process returns. The system supports discount codes and customer reviews.

Step 1: List the Nouns

• Customer
• Product
• Category
• Price
• Inventory/Stock
• Cart
• Cart item
• Discount code
• Order
• Order item
• Shipping address
• Shipping method
• Shipment tracking
• Payment
• Refund
• Return
• Order confirmation (email)
• Shipping notification (email)
• Review
• Rating
• Admin user
• Product image

22 nouns.

Step 2: Group by Responsibility

10 candidate modules from 22 nouns. Let's examine whether that's the right number.

Merge Decisions

Should Inventory be separate from Catalog? Catalog is about what exists (product descriptions, images, categories). Inventory is about how many are available right now (stock counts, warehouse locations, restock dates). They change at very different rates — product descriptions change rarely, stock counts change constantly. Keep separate.

Should Pricing be separate from Catalog? Prices could live in the Catalog — they're a product attribute. But discount codes, sale pricing, bulk pricing, regional pricing, and coupon logic are complex enough to be their own concern. If pricing lives in Catalog, then every pricing rule change risks affecting product display. Keep separate.

Should Shopping (Cart) be separate from Orders? A cart is temporary, uncommitted, and belongs to a browsing session. An order is permanent, committed, and has legal/financial implications. They feel similar (both contain items) but have completely different lifecycles and rules. Keep separate.

Split Decisions

Should Customer and Admin be the same module? Both are "accounts" with identity and authentication. But admins have additional permissions: manage products, view all orders, process returns. Customer-specific features (saved addresses, order history, wishlists) don't apply to admins. Split into Customer Accounts and Admin Accounts — or use a single Accounts module with role-based boundaries inside it.

Decision: Single Accounts module with roles. At this scale, splitting them creates unnecessary overhead.

Step 3: Define Inside and Outside

Product Catalog

• ✅ Inside: Product names, descriptions, images, categories, product pages, product attributes (size, color, weight)
• ❌ Outside: Current stock levels (Inventory), prices and discounts (Pricing), customer reviews (Reviews), how to ship it (Fulfillment)

Inventory

• ✅ Inside: Stock counts per product, warehouse locations, low-stock alerts, stock reservations (when an item is in someone's cart or mid-checkout), restock tracking
• ❌ Outside: Product details (Catalog), pricing (Pricing), order records (Orders)

Shopping (Cart)

• ✅ Inside: Adding/removing items from cart, updating quantities, cart persistence (survive browser refresh), cart expiration (after 30 days of inactivity)
• ❌ Outside: Product details displayed in the cart (Catalog), prices shown (Pricing), stock availability checks (Inventory), placing the order (Orders)

Pricing

• ✅ Inside: Base price lookups, discount code validation, discount calculation, sale/promotional pricing rules, tax calculation, bulk pricing tiers
• ❌ Outside: Product details (Catalog), cart management (Shopping), payment processing (Payment), order recording (Orders)

Orders

• ✅ Inside: Creating an order from a cart, recording order items, storing shipping address and method, tracking order status (confirmed → processing → shipped → delivered), order history for customers, cancellation logic
• ❌ Outside: Payment processing (Payment), physical shipment (Fulfillment), price calculation (Pricing), stock management (Inventory), sending confirmation emails (Communication)

Payment

• ✅ Inside: Charging credit cards, processing refunds, payment method storage (tokenized), payment confirmation, handling payment failures (retry, alternative methods)
• ❌ Outside: What was ordered (Orders), shipping details (Fulfillment), product info (Catalog)

Fulfillment

• ✅ Inside: Generating shipping labels, tracking shipment status, delivery confirmation, handling returns (receiving returned items, inspecting condition), return shipping labels
• ❌ Outside: Order details beyond what to ship (Orders), payment/refund processing (Payment), customer notification (Communication)

Communication

• ✅ Inside: Email templates, sending emails, push notifications, SMS, delivery tracking, communication preferences
• ❌ Outside: Deciding when to communicate (other modules trigger), order details (Orders), payment details (Payment)

Reviews

• ✅ Inside: Submitting reviews, editing reviews, review moderation, star ratings, calculating average rating, displaying reviews
• ❌ Outside: Product details (Catalog), customer identity (Accounts), order verification ("did this customer actually buy this product?" — needs to ask Orders)

Accounts

• ✅ Inside: Registration, login/logout, password management, profiles, roles (customer vs. admin), saved addresses, authentication tokens
• ❌ Outside: Order history (Orders), cart contents (Shopping), payment methods (Payment — though this is debatable)

Step 4: Connection Diagram

┌──────────┐                    ┌──────────┐
│ Accounts │◄──── "who is      │ Shopping  │
│          │       this?" ─────│  (Cart)   │
│- identity│                    │- items    │
│- roles   │                    │- quantities│
└──────────┘                    └──────────┘
     ▲                              │ │
     │                    "product  │ │ "what's in
     │                     info?"   │ │  the cart?"
     │                              ▼ │
     │                         ┌────────┐            ┌──────────┐
     │                         │Catalog │◄───────────│  Search  │
     │                         │        │ "find      │(if added)│
     │                         │-products│ products"  └──────────┘
     │                         │-images │
     │                         └────────┘
     │                              ▲
     │              "product info?" │
     │                              │
     │    ┌──────────┐        ┌──────────┐
     │    │Inventory │◄───────│ Pricing  │
     │    │          │"is it  │          │
     │    │- stock   │ in     │- prices  │
     │    │- reserves│ stock?"│- discounts│
     │    └──────────┘        └──────────┘
     │         ▲                    ▲
     │         │ "reserve stock"    │ "calculate total"
     │         │                    │
     │    ┌────────────────────────────┐
     │    │         Orders             │
     │    │                            │──────►┌──────────┐
     │    │ - order records            │"charge"│ Payment  │
     │    │ - status tracking          │       │          │
     │    │ - history                  │◄──────│- charges │
     │    └────────────────────────────┘ "paid" │- refunds│
     │              │        │                  └──────────┘
     │   "ship this"│        │"order confirmed"
     │              ▼        ▼
     │    ┌──────────┐  ┌──────────────┐
     │    │Fulfillment│  │Communication │
     │    │           │  │              │
     │    │- shipping │──►│- emails      │
     │    │- returns  │  │- notifications│
     │    └──────────┘  └──────────────┘
     │                        ▲
     │                        │ "did they buy it?"
     │                   ┌──────────┐
     └───────────────────│ Reviews  │
       "who wrote this?" │          │
                         │- ratings │
                         └──────────┘

Interesting Boundary Decisions

Where does "stock reservation" live?

When a customer adds an item to their cart, should that item be reserved (so it doesn't sell out while they're browsing)? If so, who manages that?

Option A: Shopping (Cart) tells Inventory to reserve stock.

• Pro: Stock is reserved early, fewer disappointed customers at checkout
• Con: Cart is coupled to Inventory. What about abandoned carts? Reservations must expire.

Option B: Stock is only reserved at checkout, when the Order is created.

• Pro: Simpler. Inventory only talks to Orders, not to Cart.
• Con: Customer shops for 20 minutes, goes to checkout, and finds out the item sold out.

Option C: No reservation. First to complete checkout gets it.

• Pro: Simplest. No reservation management at all.
• Con: High-demand items cause frustration.

Decision for this design: Option B. Reserve at checkout. The tradeoff is acceptable for most e-commerce, and it avoids complex cart-inventory coupling. For flash sales or limited editions, implement Option A with short expiry times (10 minutes).

Should Payment handle refunds, or should Fulfillment?

A return triggers a refund. Who initiates it?

Option A: Fulfillment receives the return, inspects it, and calls Payment to refund.

• Pro: Refund happens at the right moment (item received and inspected)
• Con: Fulfillment is coupled to Payment

Option B: Fulfillment marks the return as "received and approved." Orders sees this and tells Payment to refund.

• Pro: Orders is the orchestrator — it already connects to Payment. Fulfillment stays focused on physical goods.
• Con: Extra hop (Fulfillment → Orders → Payment instead of Fulfillment → Payment)

Decision: Option B. Orders is already the bridge between the digital and physical world. Adding refund orchestration to Orders keeps Fulfillment focused on shipping.

Where do "product reviews" verify purchase?

A review should only be written by someone who bought the product. The Reviews module doesn't have order data.

Reviews must ask Orders: "Did customer X buy product Y?" This is a cross-boundary query, and it's the right design — Reviews shouldn't duplicate order data just to check this.

Comparing Library vs. E-Commerce

The key takeaway: more complex domains need more boundaries, but each boundary should still pass the elevator test. If you can't explain a module in one sentence, it's too big — regardless of how complex the overall system is.