Designing with DDD

Microservices fail when their boundaries are wrong. Domain Driven Design (DDD) provides the blueprint for drawing those boundaries based on business logic, not technical convenience.

1. Bounded Contexts

A 'Product' in a Warehouse context means dimensions and weight. A 'Product' in a Sales context means price and marketing description. Instead of one giant `Product` class, DDD creates two separate models in two separate **Bounded Contexts**. This prevents 'Big Ball of Mud' architectures.

2. Aggregates and Roots

An Aggregate is a cluster of objects treated as a single unit for data changes. The **Aggregate Root** (e.g., an `Order`) is the only gatekeeper. You never modify an `OrderItem` directly; you ask the `Order` to add it. This ensures business rules (invariants) are always enforced.

4. Interview Mastery

Q: "How do you handle relationships BETWEEN microservices without 'Join' queries?"

Architect Answer: "We use **Data Duplication** and **Eventual Consistency**. If the 'Shipping' service needs the user's name, it shouldn't call the 'Identity' service every time. Instead, it listens for a `UserCreated` event and stores a local copy of the ID and Name. We trade storage for performance and availability. The source of truth remains with Identity, but Shipping has what it needs to work independently."