3-line summary
• DDD is not a single book — it's a collaboration written by three authors a decade apart. Evans gave us the language of the domain model, Vernon gave us the pragmatism of implementation, Greg Young gave us time through events.
• The biggest misconception — "aggregates must reference each other only by ID" is Vaughn Vernon's rule, not Evans's original. Evans actually allowed direct object references, and he had four reasons for doing so.
• The Java ecosystem's DDD revival was not a coincidence. September 2000 POJO coined → 2002 Rod Johnson's Spring → 2003 Fowler's Anemic Domain Model → 2003 Evans's DDD book were nearly simultaneous events. That same wave carried into the era of actors (Akka), DDD-native frameworks (Axon), and Kafka-driven event sourcing.
✍️ Author note — Akka & DDD overseas → Akka, DDD, and My Overseas Developer Years — An Author's Note
🌐 Read in Korean (한국어 원문) → DDD가 만든 세 갈래 길 — 에릭 에반스, 반 버논, 그렉 영을 다시 읽어야 하는 이유
1. Why DDD, again, right now?
In 2026, AI coding agents auto-generate half the boilerplate, Kafka has settled in as the event backbone, and the actor model has emerged as the standard abstraction for multi-agent architectures. At exactly this moment, opening DDD (Domain-Driven Design) again is no nostalgia — it's a working decision.
The domain model is the business language humans understand, and it's the cleanest surface AI agents can work on. Axon Framework natively supporting MCP (Model Context Protocol) is the proof — agent-ready systems are, in the end, systems where the domain is cleanly partitioned.
Yet too many engineers learned DDD as if it were one book. In truth, DDD is a collaboration written by three authors over a decade, and their positions partly conflict. This article pins down exactly where they conflict, and then traces how that disagreement carried into the actor / Kafka / agent era of 2026.
2. The Three Thinkers — Who Built What
Person | Publication | Contribution | Core message |
Eric Evans | 2003 "Domain-Driven Design" | Founder | Ubiquitous language, aggregates, bounded contexts |
Vaughn Vernon | 2013 "Implementing Domain-Driven Design" (IDDD) | Implementation evangelist | Patterns for actual code/frameworks, small aggregates, identity-only reference rule |
Greg Young | 2010 CodeBetter article + talks | Founder of Event Sourcing + CQRS | Express the domain as a stream of facts, not last-known state; separate write and read models |
Korean readers sometimes call him "Eric Young." The right name is Greg Young. He coined the term CQRS and formalized event sourcing in its modern sense.
2.1 The picture all three drew together
- Evans (2003): "Put the domain straight into the code. The object graph itself is the business."
- Vernon (2013): "To actually implement Evans's picture, we need rules — keep aggregates small, draw transaction boundaries clearly, and link to other aggregates only by ID."
- Young (2010~): "The truth of a domain isn't its final state — it's the stream of events that got it there. And the write model and the read model are different models."
These three positions are not different answers — they are answers from different stages. The biggest misunderstanding is unpacked in §4.
3. The Java World's Late Awakening, and the POJO Movement
Just before DDD arrived, the Java world was buried under the weight of EJB (Enterprise JavaBeans). Data lived in EntityBeans, logic in SessionBeans — the domain was split in two, and the anemic domain model had hardened into a de facto standard.
3.1 Four near-simultaneous events
When | Event | Meaning |
2000-09 | Martin Fowler · Rebecca Parsons · Josh MacKenzie coined the term POJO | "Why is nobody using regular objects? Because they didn't have a fancy name." → restoring value to plain Java objects |
2002 | Rod Johnson, "Expert One-on-One J2EE Design and Development" → Spring Framework is born | Rejecting EJB, POJO-based enterprise |
2003-11-25 | Martin Fowler, "Anemic Domain Model" bliki post — anti-pattern named | Data-only objects are an OOP violation, in print |
2003 | Eric Evans, "Domain-Driven Design" published | The theoretical skeleton the POJO movement had been waiting for |
These four events are essentially one breath. The Java world was already shaking off EJB's residue and returning to POJO + domain model — DDD gave that return a name and a structure.
3.2 Vaughn Vernon's bilingual experience
Vaughn Vernon is a developer with 35+ years of experience across both Java and C#. His IDDD book is written with Java examples, but deliberately structured to be applicable to C# developers as well. He later created the VLINGO XOOM platform — JVM main, with a C# port running alongside.
The original Korean memo behind this article phrased it as "Vernon learned it in .NET and ported it to Java." The strict primary source for that exact framing is hard to pin down. What is clear is this:
- Greg Young, who coined CQRS, started in the .NET ecosystem and influenced the Java side (CodeBetter 2010).
- Vernon was the first author who deliberately framed the vocabulary in a way both communities could share.
- Martin Fowler joined that current and recomposed the Java ecosystem around POJO + domain model.
It's less accurate to say "Java was late," and more accurate to say this was the moment both ecosystems carried each other's conclusions across the bridge.
4. The Biggest Misunderstanding — Aggregate Reference: Object or ID?
This section is the heart of the article. "Aggregates must reference other aggregates only by ID" — this rule is one of the four core guidelines in Vaughn Vernon's IDDD, not Evans's original.
4.1 Evans's original position — Object reference + Traversal
Evans's original is explicit on these points:
- External objects may reference only the root. They do not reach into other aggregates' internal objects.
- Internal objects are reached by traversal from the root. You don't grab them directly from outside.
- Only aggregate roots can be obtained directly with database queries. Everything else is reached by association traversal.
Here is the key — Evans explicitly stated that one aggregate's root may hold a direct object reference to another aggregate's root. Exactly what the original memo intuited.
4.2 Evans's four reasons for allowing object references
- Natural mapping to OOP — DDD is OOP-based. Domain associations naturally translate into object pointers; that's how object-oriented thinking expresses relationships.
- Cohesion and expressiveness of associations — Object reference brings cohesiveness; ID lookup brings decoupling. A good design blends both — only that mix is genuinely easy to understand.
- Defense against database-centric drift — If every access becomes a query, domain logic leaks into clients and query code, and entities degenerate into data containers.
- The era of object databases — When Evans was writing in 2003, OODBMSs like GemStone, Versant, and db4o were actively considered alongside RDBMS. In that environment, traversing an in-memory object graph was the most natural expression of a domain relationship.
Evans himself warned: "Resolving every access through references creates a tangled web." Extremes are dangerous on both sides.
4.3 Vaughn Vernon's identity-reference rule — Four reasons
Evans (2003) | Vernon IDDD (2013) |
External code may hold an object reference to another aggregate's root | Only by identity |
Combine traversal and search | All inter-aggregate associations are inferred through identifiers |
OOP cohesion of the object-DB era | Preserve consistency boundaries + prepare for distribution |
- Preserving consistency boundaries — A referenced aggregate is not placed inside the consistency boundary of the one referencing it.
- Performance / Scalability — Look up dependent objects before invoking a command method and pass them in. Don't inject repositories or domain services directly into aggregates.
- Distribution readiness — Another aggregate may live on another node. Object references break in distributed environments.
- Pragmatic simplicity — Small aggregates + ID references = clear transaction boundaries.
4.4 Who is right? — Both. The answer is the context.
Environment | Where Evans's answer fits | Where Vernon's answer fits |
Single process, JPA, small system | Object reference — JPA @ManyToOne is natural and raises cohesion | — |
Distributed microservices, multi-node | — | Identity reference — you cannot hold an object on another node |
Event sourcing + CQRS | — | Identity reference — events always carry only IDs |
Deep object-graph traversal IS the essence of the domain | Object reference — forcing identifiers couples the domain to the data model | — |
The intuition from the original Korean memo — "doesn't it feel ugly to swap JPA links for raw IDs?" — is exactly Evans's cohesion logic. In a single-process + JPA environment, object references really are more natural. But if that system might evolve toward distribution, migrating to ID references early lowers the future migration cost.
A balanced conclusion: the order Evans → Vernon → Young is not different answers — it's answers for different environments. From OOP to distribution, from distribution to events; as the environment shifted, so did the right answer.
5. Three Lineages of DDD Frameworks
The frameworks that actually implement DDD split into three (now four) lineages.
5.1 Actor-based — Vaughn Vernon's other book
In 2015, Vernon published **"Reactive Messaging Patterns with the Actor Model"** (Addison-Wesley), subtitled "Applications and Integration in Scala and Akka."
The actor model is the most natural way to implement DDD in the modern enterprise.
The reasoning is clean:
- Actor = own state + asynchronous messages — that is, aggregate + domain events.
- Location transparency — in a distributed environment, ID references become natural.
- Supervision — first-class expression of domain failure policies.
That current flowed into his VLINGO XOOM platform (JVM main, C# port). The framing is not "Akka happens to be DDD-friendly" — it's Vernon re-expressing DDD through the actor model, and that re-expression sat on top of the Akka community.
5.2 The DDD-dedicated framework — Axon Framework
Axon Framework is, without contest, the JVM world's #1 toolkit dedicated to DDD/CQRS/Event Sourcing.
- 70M+ downloads (the largest open-source DDD toolkit on the JVM)
- Latest major (as of 2026): Async-Native API, distributed saga orchestration, eventual-consistency guarantees (v6 line — for exact GA dates, consult the Axoniq release notes)
- Axon Server: distributed command bus + event bus + query bus + event store in one package
- Native MCP support — evolution toward agent-ready systems
According to Axoniq's 2026 benchmark, raising an event processor's batch size from 1 to 500 lifts the replay rate from 260 events/sec to 4,000 events/sec — roughly 15×.
5.3 The non-actor lineage — Spring Modulith, Eventuate
- Spring Modulith (2022, VMware/Spring team): expresses DDD bounded contexts as modules inside a Spring application.
@ApplicationModuleannotations + ApplicationEvent-based inter-module communication + automatic dependency-graph verification viaApplicationModules.verify(). First choice when you want to cleanly separate contexts inside a single deployable, before you commit to microservices.
- Eventuate Tram + Eventuate ES (Chris Richardson, author of Microservices Patterns): first-class support for saga orchestration + the Transactional Outbox pattern. Sits on top of Kafka/RabbitMQ to handle domain events and distributed transactions together. Integrates naturally with Spring Boot/Quarkus.
They don't use the actor model, but event sourcing and the flow of domain events are the common ground. The 2026 Java-world DDD decision boils down to four lineages: "actor (Akka/VLINGO) vs dedicated (Axon) vs modular (Modulith) vs saga-centric (Eventuate)."
6. The Kafka Golden Age — The Infrastructure Standard for Event Sourcing
When Greg Young formalized event sourcing in the early 2010s, the infrastructure simply wasn't ready. In the 2020s, Apache Kafka has settled in as the infrastructure standard for event sourcing.
6.1 Why Kafka and event sourcing fit so well
- Append-only log — matches the core abstraction of event sourcing one-to-one.
- Partition by aggregate ID — events for the same aggregate land in the same partition, preserving order.
- Log compaction — a retention policy that keeps only the latest snapshot per key — lets you rebuild current state without dragging the entire history along.
6.2 Nine Kafka design patterns (arxiv research, 2025-12)
An arxiv paper published in December 2025 identifies nine recurring patterns in Kafka-based event-streaming systems:
- Log compaction
- CQRS bus — commands are written as events; separate consumers project them into read models
- Exactly-once pipelines
- CDC (Change Data Capture) — Debezium streams RDB row changes as events
- Stream-table joins
- Saga orchestrator — controlling distributed transaction flow
- Tiered storage
- Multi-tenant topics
- Event sourcing replay — combining snapshots, compaction, and retention policy
From a DDD perspective, the three most important are CQRS bus, Saga orchestrator, and Event sourcing replay. When those three are combined, Greg Young's model is alive and running on top of Kafka.
6.3 What Kafka doesn't solve — and why DDD-native frameworks sit on top
Kafka is an "event backbone," not a "domain-model expression tool." That's why the following stack on top of it:
- Axon Server + Axon Framework — the layer above Kafka. First-class expression of domain events, aggregates, and sagas.
- Akka Persistence (+ Akka Cluster Sharding) — persists actors themselves into an event store + shards them across the cluster for distribution.
- Eventuate Tram — adds Outbox + Saga patterns on top of Kafka.
That is, the standard stack in 2026 looks like:
[ Domain-model expression ] Axon / Akka / VLINGO ↓ [ Event backbone ] Kafka (+ Debezium CDC) ↓ [ Storage ] RDBMS, EventStoreDB, S3 tiered
7. Why DDD Survives in the AI Era
Back to the opening question — why DDD, right now.
There are three answers.
- AI agents understand the language of the domain best. The better the ubiquitous language is established, the more accurately the AI works. Axon making MCP a first-class citizen is exactly that signal.
- Event sourcing is perfect training data for AI. Every decision a system has made remains as a fact — agents can replay and analyze the past with precision.
- The actor model has become the standard for multi-agent architectures. Nobody in 1973 predicted that Carl Hewitt's actor would become the natural abstraction for AI agents in 2026, yet that is exactly where we converged.
7.1 Three authors, three roads, one whole
Author | The answer of their era | What it means in 2026 |
Eric Evans | Language of the domain model | The surface AI agents work on |
Vaughn Vernon | ID references + actor model | The default shape of distributed multi-agent systems |
Greg Young | CQRS + Event Sourcing | The data flow of the Kafka + LLM era |
The three together are not different answers — they are different stages. The impression that DDD ends with a single book is misguided. The 10-year gap between the three authors' publications, plus the 23 years of actors · Kafka · AI built on top of them, together make up the DDD of right now.