Back to Code | Ep 05: The Revenge of Context — DDD and Bounded Contexts

The 15-week technical battle of LogiFlow — a company waking up from the illusion created by artificial intelligence and returning to real engineering.

The Story

The system crashed because of the word "Return."

Customer Return and Truck Depot Return got mixed up. AI had created a single ReturnEntity class for both. The God Object was born.

It started with a simple bug report: a warehouse manager saw a customer refund amount appear on his truck cargo screen. A developer traced the issue back to a single class — Return — that served billing, logistics, and warehouse contexts simultaneously. Every time one team added a field, another team's feature broke.

Technical Autopsy: The God Object

// AI's God Object that confuses every context
class Return {
  id: string;
  customerId?: string;    // Billing context
  truckId?: string;       // Logistics context
  warehouseId?: string;   // Warehouse context
  reason: string;
  refundAmount?: number;  // Finance context
  weight?: number;        // Logistics context
  hazmatFlag?: boolean;   // Compliance context
  // ... and 20+ more fields
}

Every optional field was a lie. Every ? was a question the system couldn't answer: "Which context am I in right now?"

When the billing team needed to calculate a refund, they had to navigate past truckId, warehouseId, and hazmatFlag — fields that meant nothing in their world. When the logistics team needed to reroute a cargo return, they stumbled over refundAmount and customerId.

"AI sees one word and creates one class. But in the real world, one word carries different meanings in different rooms. A 'Return' in accounting is money. A 'Return' in the warehouse is weight and hazmat compliance."

The Human Solution: Bounded Contexts

// Context 1: Billing
class CustomerRefund {
  customerId: string;
  amount: Money;
  currency: Currency;
}

// Context 2: Logistics
class TruckCargoReturn {
  truckId: string;
  warehouseId: string;
  weight: Kilogram;
  hazmatFlag: boolean;
}

Two classes. Zero optional fields. Each one speaks the language of its own domain. Each one is independently testable, deployable, and understandable.

Ubiquitous Language: The same word means different things in different domains. AI cannot draw this philosophical boundary.

Why This Matters

Domain-Driven Design isn't an academic exercise. It's the difference between a system that scales with your organization and one that turns every feature request into an archaeological expedition.

When Defne drew the context boundaries on the whiteboard, something clicked for the team. It wasn't just about code — it was about communication. The billing team and the logistics team had been talking past each other for months, and the God Object was the technical manifestation of that miscommunication.

Lessons from Episode 5

1. Bounded Contexts: An entity is not the same in every context. "Return" is money in Billing, weight in Logistics.

2. Ubiquitous Language: Creating a shared language with domain experts is a socio-technical skill AI can never perform.

3. Entities vs Value Objects: AI cannot correctly establish the subtle philosophical difference between an Entity (defined by identity) and a Value Object (defined by value).

---

This is Episode 5 of the "Back to Code" series. Next up: Episode 6 — State Hell and Idempotency.

Series: back.to.code · 2026