Domain-Driven Design

Meet Northwind — a Small Online Retail Business

In plain English, here is everything Northwind does. No code, no database, no framework — just the business, as its three founders would describe it:

• People browse a catalog and place orders.
• Someone decides what things cost, and runs the occasional discount.
• Someone keeps track of what's actually in the warehouse.
• Someone packs boxes and hands them to a carrier.
• Someone charges the customer's card and refunds it when something goes wrong.
• Someone lets a customer log in and see their order history.

Five Words That Get Conflated

Domain and subdomain describe the business. Bounded context and ubiquitous language describe how you organize the code and words around it. Keep those two groups separate and most DDD confusion disappears.

The Bug: Two Teams, One Word, Two Meanings

Northwind grew. Now there's an Ordering team and a separate Inventory team, each shipping its own service. Both use a type called Product.

// InventoryService — "price" is the wholesale cost Northwind pays the supplier
class Product { sku: string; price: number; stockCount: number; }

// OrderService — imports the SAME Product type from a shared "models" folder
function calculateTotal(product: Product, qty: number) {
  return product.price * qty;   // customer is charged supplier COST, not retail price
}

Systems Don't Fail on Day One — They Fail as They Grow

• Early Northwind succeeded because the three founders held the whole mental model in their heads.
• Later Northwind failed because that model fractured: teams grew apart, terminology drifted — exactly what caused the bug on the last slide.
• Features get bolted on without design consideration. Every new requirement piles more special cases onto assumptions that are already stale.
• This is rarely a tooling problem — it's a modeling problem. That's exactly the moment Domain-Driven Design (DDD) targets.

Model the Business, Not the Database

The term traces back to Eric Evans' 2003 book Domain-Driven Design: Tackling Complexity in the Heart of Software — Entity, Value Object, Aggregate, Domain Event, Repository all come from that book by name.

DDD is an approach to software design that puts the business domain — not the schema, not the framework — at the center of every decision. It requires engineers to collaborate deeply and continuously with domain experts, not just gather requirements once and disappear into tickets.

• Not a silver bullet. DDD doesn't generate code and won't fix a legacy monolith by itself.
• What it gives you instead: clarity about what the system should do, and where it's safe to change.
• Architecture-agnostic. Works for a monolith or microservices — what matters is whether the model reflects real domain rules.

A cheatsheet on Domain-Driven Design — ByteByteGo

A Repeatable Method — Not Guesswork

1. List what the business does, in the founders' own words.
2. Does a shared word change meaning here? "Product" differs between stock-counting and cart-building — that shift is a signal.
3. Does a different group decide here, on a different rhythm? Pricing changes daily; login barely changes at all.
4. Group by how much each matters:
   • Core — Order Management, Pricing
   • Supporting — Inventory, Fulfillment
   • Generic — Payments Gateway, Auth

Legacy codebase? Same method — look for a class name used two different ways, or a "simple" change needing another team's sign-off.

Context	Owns	Core model
Order Mgmt	Orders, checkout	Order, OrderLineItem
Inventory	Stock, SKUs	Product, StockCount
Payments	Charges, refunds	PaymentAttempt (via ACL)

This is a candidate, not a final answer. Northwind proposed splitting "Pricing" out of Order Management — discussion revealed no real seam, and it merged back in. Propose → discuss → reject or merge → standardize.

One Word, One Meaning — Inside a Context

Ubiquitous language is a shared vocabulary developers and domain experts use everywhere, for one bounded context. Applied to the bug from Slide 4:

// After a 15-minute glossary conversation with the business:
// "price" the business pays a supplier is a WholesaleCost.
// "price" the customer pays is a RetailPrice. Never the same field.
class Product { sku: string; wholesaleCost: Money; retailPrice: Money; stockCount: number; }

function calculateTotal(product: Product, qty: number) {
  return product.retailPrice.multiply(qty);   // unambiguous
}

Pros: shared meaning, readable code, better decisions. Cons: upfront workshop effort; sloppy naming breaks the whole benefit.

There Is No Company-Wide Glossary

Ubiquitous language is scoped per bounded context — not company-wide. Each context gets its own internally-consistent vocabulary:

• Inside Order Management, "Product" always means a purchasable line item.
• Inside Inventory, "Product" always means a stocked SKU with a wholesale cost.
• Neither definition is wrong. Neither team needs to "win" — they just must never share the same class.

Make the Confusion Structurally Impossible

Renaming one field fixes one bug. It doesn't stop the next team from importing the wrong Product again. A bounded context gives each meaning its own model.

// inventory-context/Product.ts — not shared
class Product { sku: string; wholesaleCost: Money; stockCount: number; }

// order-context/Product.ts — not shared
class Product { sku: string; retailPrice: Money; }

A bounded context isn't automatically a microservice — it can be a module inside one monolith. It's the model-and-language boundary that counts, not the deployment.

Level Up Coding — same word, different meanings across bounded contexts

Inside a Context: Identity vs. Attributes

• Entity — defined by identity and lifecycle. A Customer stays the same person even after their address changes. Entities are mutable.
• Value Object — defined only by its values, often immutable. Money has no identity of its own. Value objects are immutable.

// Entity — has an ID that outlives any single attribute
class Customer {
  constructor(public readonly id: string, private address: Address) {}
  relocate(newAddress: Address) { this.address = newAddress; } // same customer, new address
}

// Value Object — immutable, compared by value, no ID
class Money {
  constructor(public readonly amount: number, public readonly currency: string) {}
  multiply(qty: number) { return new Money(this.amount * qty, this.currency); }
}

DDD Is a Tool, Not a Default