Domain-Driven Design (DDD): Bounded Contexts & Ubiquitous Language

In traditional monolithic systems, developers instinctively strive to build a single, universal data model. Every table and entity is centralized: a single User class contains 80 columns representing passwords, billing addresses, shipping instructions, loyalty points, preferences, and permissions.

This creates a fragile God Object:

• Modifying a column for the logistics team risks breaking the checkout flow.
• Database queries load bloated objects with dozens of unused fields into memory.
• Multiple engineering teams constantly fight over who owns the validation rules and schema migrations for the entity.

Domain-Driven Design (DDD), introduced by Eric Evans in 2003, fundamentally rejects universal data models in favor of Bounded Contexts.

A Bounded Context is an explicit boundary within which a specific domain model applies. Inside that boundary, all terms in the Ubiquitous Language have an unambiguous, rigorously defined meaning shared by both software engineers and business domain experts.

Semantic Divergence of the "User" Entity Across Bounded Contexts:

1. Identity & Access Context:
   • Entity Name: User
   • Core Attributes: user_id, email, password_hash, mfa_secret, roles, jwt_session_id.
   • Primary Focus: Authentication, Authorization, Token Validation.
2. Billing & Payments Context:
   • Entity Name: Customer
   • Core Attributes: customer_id, stripe_customer_token, vat_number, billing_currency, credit_balance.
   • Primary Focus: Payment capture, Tax calculation, Invoicing.
3. Logistics & Fulfillment Context:
   • Entity Name: Recipient
   • Core Attributes: recipient_name, shipping_address, delivery_gate_code, courier_instructions, sms_phone.
   • Primary Focus: Packaging, Courier dispatch, Route optimization.

By defining separate bounded contexts, each microservice encapsulates its own private representation of the concept. The services reference each other strictly via immutable identifiers (e.g., user_id: UUID) rather than shared object graphs.

Within a bounded context, DDD structures data into a strict hierarchy:

• Entity: An object defined by its distinct identity that persists over time (e.g., an Order with ID ord_8923), even if its attributes change.
• Value Object: An immutable object defined entirely by its attributes with no conceptual identity (e.g., Money(amount: 50.00, currency: "USD"), Address). Two Value Objects with identical attributes are completely interchangeable.
• Aggregate: A cluster of associated Entities and Value Objects treated as a single transactional consistency boundary.
• Aggregate Root: The primary gateway Entity (e.g., Order) through which all mutations to inner child objects (e.g., OrderLineItems) must pass.

Business Invariants Enforcement:

The Aggregate Root is solely responsible for enforcing business invariants (rules that must always hold true):

typescript
Copy
class OrderAggregateRoot {
  private id: OrderId;
  private lineItems: OrderLineItem[] = [];
  private status: OrderStatus = OrderStatus.DRAFT;

  // Invariant: Cannot add items to an order that is already paid or shipped
  public addLineItem(item: OrderLineItem): void {
    if (this.status !== OrderStatus.DRAFT) {
      throw new DomainException("Cannot modify line items on a committed order");
    }
    if (this.lineItems.length >= 50) {
      throw new DomainException("Order exceeds maximum allowable line items (50)");
    }
    this.lineItems.push(item);
  }
}

Rule of Thumb: A database transaction should never modify more than one Aggregate Root at a time. Cross-aggregate coordination must use asynchronous Domain Events.

When multiple Bounded Contexts interact, DDD defines strategic Context Maps to govern their dependencies: