DDD for Interviews — Terms, Usage & How to Sell It 🧵

1/10

"You read about Ubiquitous Language. You know what an Aggregate is. You can recite the Blue Book.

And then the interviewer says: 'Design a payment system.'

Suddenly, all the DDD terms evaporate and you're drawing boxes and arrows like everyone else."

DDD isn't about vocabulary. It's about how you structure a conversation. Here's how to actually use it in interviews.

🧵

2/10

The problem DDD solves (say this in the interview)

"Most systems fail not because the code is bad, but because the code doesn't match the business thinking. Developers and domain experts use different words for the same concepts. The result: wrong abstractions, constant rework, and complexity that nobody owns."

DDD solves the translation gap between business and code.

Interview sell: "I use DDD to ensure that the code structure reflects business intent, not database structure."

3/10

Ubiquitous Language — the #1 term to mention

Meaning: One shared vocabulary across developers, PMs, QA, domain experts. The same word means the same thing in a conversation, in a Jira ticket, in a Slack thread, and in the code.

How to sell it:

"I insist that 'Refund', 'Cancellation', and 'Chargeback' each have one definition across the org — not three different meanings in support, product, and engineering."
In an interview: "The first thing I do when joining a new domain is establish a glossary with the business team."

4/10

Bounded Context — the most powerful interview concept

The key insight: A word means different things in different contexts.

Example (payment platform):

In Checkout Context: "Payment" = capturing card details
In Settlement Context: "Payment" = funds transfer to merchant
In Dispute Context: "Payment" = an active dispute case

Sell it: "I use Bounded Contexts to define team ownership boundaries. Each microservice owns exactly one context. No confusion about who owns what."

Interview tip: When asked about microservice boundaries, say "I think of each service as a Bounded Context" — then explain why. This separates you from engineers who just say "split by business capability."

5/10

Aggregate — the consistency boundary

An Aggregate is a cluster of domain objects that must be consistent together. You load + save the entire aggregate as one unit.

Real example (Razorpay):

{
  "Payment": {
    "id": "pay_123",
    "status": "captured",
    "amount": 10000,
    "refunds": [],        // Part of the aggregate
    "captures": [...]     // Part of the aggregate
  }
}

Refunds and captures are CONSISTENT with the payment. You never save a refund without loading the parent payment.

Sell it: "I use Aggregates to define transactional boundaries. If two things must be consistent, they're in the same aggregate. If they can be eventually consistent, they're in separate aggregates — and separate services."

Interview gold: When asked about consistency vs. eventual consistency, your answer starts with "It depends on the Aggregate boundary."

6/10

Entity vs Value Object — the simplest differentiator

Entity: Has an identity that persists over time. A Payment with id=pay_123 is still the same Payment even if its status changes.

Value Object: Defined entirely by its attributes. Money(amount=1000, currency="INR") — if you change the amount, it's not the same object; you create a new one.

Sell it: "I use Value Objects for measurements, money, addresses, phone numbers — things with no identity. They're immutable, comparable by value, and eliminate primitive obsession."

Interview tip: Mentioning Value Objects unprompted signals you think about types, not just strings and ints.

7/10

Domain Events — decoupling without losing traceability

A Domain Event is something that happened that matters to the business. Past tense. Named in Ubiquitous Language.

Examples:

PaymentCaptured
RefundInitiated
DisputeRaised

How to use: Services publish events. Other services subscribe. No direct coupling.

Sell it: "I use Domain Events as the backbone of async communication between Bounded Contexts. Each event is named in the business language, stored in an event store, and can be replayed for debugging."

Interview move: When asked about async architecture, say "I model my event schema as Domain Events first, then worry about the messaging infra later. Kafka/PubSub is implementation detail."

8/10

Repository vs Domain Service — the tactical pattern

Repository: Abstracts data storage. "Give me the Payment with this ID." You think in aggregates, not SQL.

Domain Service: Stateless business logic that doesn't naturally fit in an Entity or Value Object. Example: FraudEvaluationService — it coordinates multiple aggregates to make a decision.

Sell it: "I keep Repositories thin (just load/save aggregates) and put real business logic in Domain Services. If a Repository is doing calculations, something is wrong."

Interview tip: Draw a layered diagram — Application → Domain (Entities, Value Objects, Domain Services) → Infrastructure (Repositories, Event Publishers). Show clear dependency direction.

9/10

How to sell DDD in a system design interview

The standard approach: "Let's design a payment system."

The DDD approach, step by step:

"Let's start by mapping the Bounded Contexts with the business team." (Shows you think in domains, not tables)
"For each context, I'll establish Ubiquitous Language." (Shows you care about semantics)
"Within the Payment Context, the Aggregate is the Payment itself — refunds and captures live inside it." (Shows tactical knowledge)
"Cross-context communication via Domain Events so services stay decoupled." (Shows architectural maturity)
"Every concept is a Value Object unless it needs an identity." (Shows type-awareness)

You're not just designing a system. You're designing a language that the system expresses.

10/10

Bottom line:

DDD isn't a framework you import. It's a way of structuring thought that produces systems where the code reads like the business.

Most engineers design in terms of tables, APIs, and queues. The best engineers design in terms of Aggregates, Domain Events, and Ubiquitous Language — and the infrastructure follows naturally.

The golden rule: A well-designed DDD system makes a domain expert say "Yes, that's how it works" — not "Close enough."

#DomainDrivenDesign #DDD #SystemDesign #StaffEngineer #InterviewPrep