طراحی دامنه‌محور (DDD)Domain-Driven Design

Let us start bluntly: many people think DDD means a pile of Java classes with pretty names (Entity, Aggregate, Repository) that you sprinkle over an ordinary app. That is the single biggest misconception about DDD. In this chapter we build it from zero — not by throwing jargon at you, but with analogies, real code, and every term unpacked. By the end you should make good decisions on a real project and survive the hardest senior-interview questions.

Part 0 — words you must feel

Before anything else, let us unpack three words with analogies so the rest of the chapter flows.

Three key words that keep coming back:

• Invariant: a rule that must always be true — like "an account balance is never negative." A law of physics inside your system.
• Consistency: data agreeing with itself so no rule is broken.
• Transaction: an all-or-nothing bundle of changes; either it all happens or none of it does (rollback).

Feel these now; we will need them repeatedly.

Mental model: DDD is about language and boundaries, not folders

Domain-Driven Design (DDD) was introduced by Eric Evans in Domain-Driven Design (2003) and refined by Vaughn Vernon in Implementing Domain-Driven Design (2013). Its central claim sounds simple but is hard in practice:

The biggest bottleneck in complex software is not technology — it is the translation loss between domain experts and code.

Let me unpack "translation loss," because it is the heart of everything.

DDD attacks that loss with three moves: (1) it makes the model of the business the primary artifact, (2) it expresses that model in a ubiquitous language — vocabulary shared by developer and expert — and (3) it enforces that language with explicit boundaries in the code. Everything else — entities, value objects, aggregates — is merely tactical machinery in service of that goal.

DDD has two halves:

Strategic DDD

The domain and its subdomains

The domain is the whole problem space your business operates in — say, "online retail." You almost never model it uniformly; you break it into subdomains. And here is the golden move: you classify subdomains by their strategic value, because that dictates where to spend engineering effort.

The three classes:

• Core domain — the part that gives competitive advantage; the reason the business exists (e.g. a fraud-scoring engine for a payments company). Build this yourself, with your best people, using rich DDD.
• Supporting subdomain — necessary but not differentiating (e.g. a customer-notes feature). Build it, but plainly; DDD-lite is fine.
• Generic subdomain — a solved problem (auth, billing, PDF generation). Buy or adopt off-the-shelf; do not lovingly hand-craft it.

The single most valuable strategic decision is identifying your core domain and not wasting modeling energy on generic subdomains. A team that builds an artisanal in-house identity system while their actual core (say, logistics routing) stays anemic has misallocated its scarcest resource: attention.

Ubiquitous language

The ubiquitous language is a rigorous, shared vocabulary — nouns, verbs, and business rules — used identically by domain experts, in conversation, in tests, and in code. "Ubiquitous" means "present everywhere": the same word in the meeting, in the test, and in the Java class.

If experts say "a policy is bound when underwriting approves it," then your code is:

policy.bind();        // the expert's language, straight in code
// not:
policy.setStatus(2);  // meaning lost — what does "2" mean?

The simple rule: fuzzy language ⇒ fuzzy model. If you cannot name a behavior with a verb from the expert's language, you don't understand it yet.

Bounded contexts

A bounded context is an explicit boundary within which a particular model — and its ubiquitous language — is consistent and complete. Inside the boundary, every term has exactly one meaning. Across boundaries, the same word may mean different things, and that is fine — the boundary is precisely what lets each team evolve its model independently.

A bounded context typically maps to:

• one team's area of ownership,
• often one deployable service (in microservices) or one module/package (in a modular monolith),
• one database schema it owns exclusively.

Here is a sharp interview point: the relationship between "bounded context" and "microservice" is not one-to-one. A bounded context is a modeling/linguistic boundary; a microservice is a deployment boundary. A well-modularized monolith can host several bounded contexts. Get the contexts right first, then decide deployment topology — because splitting into services along the wrong lines is far more expensive than merging packages.

Study this diagram — one word, two contexts, two meanings:

        Sales Context                 Shipping Context
 ┌───────────────────────┐      ┌──────────────────────────┐
 │  Customer             │      │  Recipient               │
 │  Order (draft→placed) │─────▶│  Shipment (packed→sent)  │
 │  Product (price,promo)│      │  Package (weight,dims)   │
 └───────────────────────┘      └──────────────────────────┘
   "Order" = a purchase intent    "Order" doesn't exist here;
                                   only a Shipment with items

Notice "Order" does not exist on the right at all — only a Shipment. Each team has its own language.

Context mapping

Now that you have separated contexts, you must describe how they connect. A context map documents how contexts relate — both technically and organizationally.

The standard context-mapping patterns:

"Upstream" means the context that produces the data/model; "downstream" means the one that consumes it — like a river, water flows from upstream to downstream.

The Anticorruption Layer (ACL)

Of all the patterns, the ACL deserves special emphasis, because it is the one most often needed and most often skipped.

When you integrate with a legacy system, a third-party API, or another team's messy model, do not let their concepts leak into your domain. Build an adapter that translates their vocabulary into yours. This keeps your core model clean and lets you swap the external system later without your domain falling apart.

// Our clean domain concept
public record CreditScore(int value) {
    public CreditScore {
        if (value < 300 || value > 850)
            throw new IllegalArgumentException("FICO out of range: " + value);
    }
    public boolean isPrime() { return value >= 660; }
}

// The external provider speaks a different, messier language.
// This is the Anticorruption Layer: it translates THEIR model into OURS.
public class BureauAntiCorruptionLayer {
    private final LegacyBureauClient legacyClient; // vendor SDK, foreign vocabulary

    public CreditScore fetchScore(SSN ssn) {
        // Vendor returns a bag of fields with a scale of 0..100 and status codes
        BureauResponse raw = legacyClient.query(ssn.masked());
        if (!"OK".equals(raw.getStatusFlag()))
            throw new ScoreUnavailableException(raw.getStatusFlag());
        // Translate vendor's 0..100 into our FICO 300..850 — the boundary math lives HERE, not in the domain
        int fico = 300 + Math.round(raw.getNormalizedScore() / 100f * 550);
        return new CreditScore(fico);
    }
}

Notice how all the "dirt" — the "OK" status codes, the odd 0..100 scale, the tangled fields — is jailed inside the ACL. Your domain only ever sees a clean CreditScore. Swap the vendor tomorrow and only this class changes, not the whole domain.

Tactical DDD

Now we design inside one bounded context. The tactical patterns are building blocks for a rich domain model.

Value objects

A value object models a thing defined entirely by its attributes, with no identity.

Properties of a value object:

• Immutable — once created, never mutated; "changing" it means creating a new instance.
• Equality by value — equals/hashCode over all attributes.
• Self-validating — it cannot exist in an invalid state.
• Side-effect-free behavior — methods return new values, they don't mutate.

Most of your domain rules should live in value objects. Why? Because they shrink the surface area for bugs: an invalid Money or EmailAddress simply cannot be constructed, so you never have to check for it elsewhere. Java records (finalized in Java 16) are an excellent fit; use the compact constructor to validate — a bit of code that runs before the fields are assigned, acting as a gatekeeper.

public record Money(BigDecimal amount, Currency currency) {

    // Compact constructor: runs before the fields are assigned — the validation gate
    public Money {
        Objects.requireNonNull(amount, "amount");
        Objects.requireNonNull(currency, "currency");
        if (amount.scale() > currency.getDefaultFractionDigits())
            throw new IllegalArgumentException("too many decimals for " + currency);
    }

    public Money add(Money other) {
        requireSameCurrency(other);
        return new Money(amount.add(other.amount), currency); // returns NEW instance
    }

    public Money multiply(int factor) {
        return new Money(amount.multiply(BigDecimal.valueOf(factor)), currency);
    }

    public boolean isNegative() { return amount.signum() < 0; }

    private void requireSameCurrency(Money other) {
        if (!currency.equals(other.currency))
            throw new CurrencyMismatchException(currency, other.currency);
    }
}

Notice the domain-meaningful behavior (add, multiply, isNegative) — that is the "smart employee." And crucially: adding two different currencies is impossible (it throws) rather than silently wrong. record gives you value equality and immutability for free.

Entities

An entity has an identity that persists through change.

So entity equality is by identity (ID), not by attributes — two Customer objects are equal iff their IDs are equal, regardless of current field values. Entities are mutable (their attributes change over time), but every mutation must go through methods that preserve invariants.

public class Customer {
    private final CustomerId id;        // identity — assigned once, never changes
    private EmailAddress email;          // attributes can change
    private CustomerName name;

    // equals/hashCode based ONLY on id
    @Override public boolean equals(Object o) {
        return o instanceof Customer c && id.equals(c.id);
    }
    @Override public int hashCode() { return id.hashCode(); }
}

Aggregates, aggregate roots, and invariants

This is the deepest and most misused concept in all of DDD, so read slowly.

Now in precise terms: an aggregate is a cluster of entities and value objects treated as a single unit for the purpose of data changes and consistency. One entity is the aggregate root — the only member outside code is allowed to reference. External objects hold a reference only to the root; they may never hold a reference to an internal member. All access and modification go through the root, which enforces the aggregate's invariants — rules that must hold true at the consistency boundary at the end of every transaction.

Vernon's four rules of aggregate design — memorize these, because interview question 4 is exactly this:

1. Model true invariants in consistency boundaries. Put inside one aggregate exactly what must be kept consistent immediately, transactionally. If two pieces of data must always agree at commit time, they belong in the same aggregate.
2. Design small aggregates. A large aggregate (e.g. Customer containing all their orders) causes lock contention, huge transactions, and memory bloat. Prefer many small aggregates.
3. Reference other aggregates by identity, not by object reference. An Order holds a CustomerId, not a Customer. This keeps aggregates decoupled, keeps transactions small, and lets each aggregate be loaded/persisted independently.
4. Use eventual consistency between aggregates. Anything outside the aggregate boundary is updated asynchronously (typically via a domain event), not in the same transaction. One transaction should modify exactly one aggregate instance. This is the rule most people violate.

Here is a full aggregate that enforces its invariants — watch closely how the order of check and mutation works:

// AGGREGATE ROOT
public class Order {
    private final OrderId id;
    private final CustomerId customerId;      // reference OTHER aggregate BY ID (rule 3)
    private OrderStatus status;
    private final List<OrderLine> lines;      // internal entities — never exposed by reference
    private Money total;
    private final List<DomainEvent> events = new ArrayList<>();

    private static final Money MAX_ORDER = new Money(new BigDecimal("10000"), Currency.getInstance("USD"));

    public static Order place(OrderId id, CustomerId customerId) {
        Order o = new Order(id, customerId);
        o.status = OrderStatus.DRAFT;
        o.total = Money.zero(Currency.getInstance("USD"));
        return o;
    }

    // The ONLY way to add a line — invariants enforced here, atomically
    public void addLine(ProductId product, int qty, Money unitPrice) {
        // INVARIANT 1: cannot modify a placed order
        if (status != OrderStatus.DRAFT)
            throw new OrderNotModifiableException(id, status);
        // INVARIANT 2: quantity must be positive
        if (qty <= 0)
            throw new IllegalArgumentException("qty must be > 0");

        Money newTotal = total.add(unitPrice.multiply(qty));
        // INVARIANT 3: total must not exceed the cap — checked BEFORE mutating state
        if (newTotal.isGreaterThan(MAX_ORDER))
            throw new OrderLimitExceededException(newTotal, MAX_ORDER);

        lines.add(new OrderLine(product, qty, unitPrice));
        this.total = newTotal;   // state changes only after all checks pass
    }

    public void place() {
        if (status != OrderStatus.DRAFT)
            throw new IllegalStateException("already placed");
        // INVARIANT 4: an order must have at least one line to be placed
        if (lines.isEmpty())
            throw new EmptyOrderException(id);
        this.status = OrderStatus.PLACED;
        // Anything OUTSIDE this aggregate reacts via an event, in a SEPARATE transaction (rule 4)
        events.add(new OrderPlaced(id, customerId, total, Instant.now()));
    }

    // Expose an UNMODIFIABLE view — callers can read, but cannot bypass the root
    public List<OrderLine> lines() { return Collections.unmodifiableList(lines); }

    public List<DomainEvent> pullEvents() {
        List<DomainEvent> copy = List.copyOf(events);
        events.clear();
        return copy;
    }
}

Burn three things from this code into memory:

1. Invariants are checked before any state mutates, so a rejected operation leaves the aggregate untouched (no partial mutation).
2. The collection is exposed only as an unmodifiable view (unmodifiableList) — nobody can sneak a line in behind the root's back.
3. Cross-aggregate effects (decrementing inventory, awarding loyalty points) happen via the OrderPlaced event, not inline and not in this same transaction.

Domain events

A domain event records something meaningful that happened in the domain, always in the past tense: OrderPlaced, PaymentCaptured, ShipmentDispatched. They are immutable value objects.

Domain events are the primary mechanism for eventual consistency between aggregates and for decoupling the core model from side effects. The aggregate "raises" the event; an application-layer dispatcher publishes it after the transaction commits; handlers in the same or other contexts react.

public record OrderPlaced(OrderId orderId, CustomerId customerId,
                          Money total, Instant occurredOn) implements DomainEvent {}

In Spring, the idiomatic way is ApplicationEventPublisher with @TransactionalEventListener(phase = AFTER_COMMIT) so publication happens after the transaction commits — so a handler never reacts to a change that later rolls back:

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void on(OrderPlaced event) {
    // runs only if the order transaction actually committed
    inventoryService.reserve(event.orderId());   // its own transaction, its own aggregate
}

Repositories

A repository provides the illusion of an in-memory collection of aggregate roots. That is, it lets your code work with aggregates as if they all sat in a List in memory, while behind the scenes it loads/stores them from the database.

Key rules:

• One repository per aggregate root — not per table, not per entity.
• Its interface belongs to the domain layer and speaks the ubiquitous language; the implementation lives in infrastructure.
• Repositories load and store whole aggregates, never partial internals.

// Domain layer — an interface, expressed in domain terms
public interface OrderRepository {
    Optional<Order> findById(OrderId id);
    void save(Order order);            // persists the WHOLE aggregate
    List<Order> findOpenOrdersFor(CustomerId customer);
}

Domain services

Sometimes a piece of domain logic doesn't naturally belong to any single entity or value object — usually because it coordinates several aggregates or is a stateless calculation. Model it as a domain service.

A domain service has no identity or state; it's named after an activity in the ubiquitous language (FundsTransferService, PricingService). Don't confuse it with an application service:

• Domain service = business logic that doesn't fit one entity.
• Application service = a use-case orchestrator that manages transactions and calls repositories (orchestration, not business rules).

// Coordinates two Account aggregates — belongs to neither, so it's a domain service.
public class MoneyTransferService {
    public void transfer(Account from, Account to, Money amount) {
        from.withdraw(amount);  // each aggregate enforces its own invariants
        to.deposit(amount);
        // Note: the APPLICATION service decides transaction scope; ideally these
        // are two aggregates reconciled via events, not one 2-aggregate transaction.
    }
}

Factories

When constructing an aggregate is complex — many invariants, assembling internal objects, choosing a subtype — a factory encapsulates that creation so a valid aggregate is born consistent.

Mapping aggregates to persistence

There is a fundamental tension here: the relational model (tables and rows) and the aggregate model (nested, behavior-rich objects) fight each other. DDD calls this the object-relational impedance mismatch — like fitting a round shape into a square hole.

Two approaches:

• Ideal: persistence ignorance. Domain objects have no ORM annotations; a separate mapping layer translates. Keeps the model pure but costs boilerplate.
• Pragmatic: JPA on the entities, accepting some coupling. If you do this, respect aggregate boundaries: @OneToMany(cascade = ALL, orphanRemoval = true) from root to internals so the aggregate is saved/deleted as one unit; but never map a JPA association from one aggregate root to another — store the foreign ID as a plain value (CustomerId) instead.

@Entity
public class Order {
    @EmbeddedId private OrderId id;

    // internal entity: cascade so the whole aggregate persists atomically
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "order_id")
    private List<OrderLine> lines = new ArrayList<>();

    // OTHER aggregate: store the ID only — NOT @ManyToOne Customer
    @Embedded private CustomerId customerId;
}

Value objects map naturally to JPA @Embeddable/@Embedded (inlined columns), or in Java to record-backed types via an AttributeConverter. And for read-heavy queries that span aggregates, do not contort the domain model — use CQRS.

Where DDD pays off — and where it's overkill

Let us be honest: DDD is not free. Rich modeling, ubiquitous-language discipline, and boundary maintenance take time and energy. So when is it worth it?

It pays off when:

• The domain is genuinely complex — non-trivial business rules, many edge cases, invariants that evolve (insurance, trading, logistics, healthcare billing).
• The system is long-lived and maintained by rotating teams.
• You have access to domain experts to build the ubiquitous language — without them, DDD is impossible, not just hard.

It's overkill when:

• The app is essentially CRUD — forms over data with thin rules. A transaction-script or active-record style is cheaper and clearer; forcing aggregates adds ceremony with no invariant to protect.
• It's a short-lived tool, prototype, or throwaway.
• The subdomain is generic — don't lovingly model what you should buy.

Common pitfalls & gotchas

• Anemic domain model. Getters/setters + "service" classes holding all logic. It's OOP in name only; invariants scatter and re-open the translation gap.
• Aggregates too big. A Customer owning all orders → lock contention, giant transactions, memory blowups. Prefer small aggregates referencing by ID.
• Modifying multiple aggregates per transaction. Re-couples them and invites deadlocks. One aggregate per transaction; cross-aggregate via events + eventual consistency.
• Exposing internal collections. return lines; lets callers bypass the root's invariants. Return unmodifiable views.
• Bounded context = microservice, always. No. Context is linguistic/modeling; service is deployment. Get contexts right first.
• Skipping the ACL and letting a vendor/legacy model bleed into your core.
• Repositories that are DAOs. Query-method soup erodes the ubiquitous language and leaks persistence into the domain.
• DDD everywhere, including generic subdomains and CRUD. Misallocated effort; the classic over-engineering trap.
• Ignoring Conway's Law. Context boundaries that cut across team ownership will erode; align them.

Interview Questions

Each question is in its own block. Try answering yourself first, then open the answer.

public List<OrderLine> getLines() { return lines; }        // returns the live internal list
public void addLine(OrderLine l) { total = total.add(l.subtotal()); lines.add(l); }

record Basket(List<String> items) {}
var list = new ArrayList<>(List.of("a"));
var b = new Basket(list);
list.add("b");
System.out.println(b.items().size());