3줄 요약
• DDD는 한 권의 책이 아니라 세 명의 작가가 시간차로 만든 합작이다. 에반스가 도메인 모델의 언어를, 버논이 구현의 실용성을, 그렉 영이 이벤트로 시간을 풀었다.
• 가장 큰 오해 — "애그리거트는 ID로만 참조해야 한다"는 반 버논의 규칙이지 에반스의 원본이 아니다. 에반스는 객체 참조도 허용했고 그렇게 한 데는 네 가지 이유가 있다.
• 자바 진영의 DDD 부활은 우연이 아니다. 2000년 POJO 명명 → 2002 Rod Johnson Spring → 2003 Fowler Anemic Domain Model → 2003 에반스 DDD 책 출판의 거의 동시다발 사건이었다. 그 흐름이 액터(Akka), 전용 프레임워크(Axon), 카프카 이벤트 소싱 시대로 이어졌다.
✍️ 작성자 회고 — 해외에서 만난 Akka·DDD → Akka와 DDD, 그리고 해외 개발 경험 이야기 — 작성자 회고
1. 왜 지금 DDD를 다시 보는가
2026년, AI 코딩 에이전트가 보일러플레이트 절반을 자동 생성하고, 카프카가 이벤트 백본으로 자리 잡고, 액터 모델이 멀티 에이전트 아키텍처의 표준 추상으로 떠올랐다. 이 시점에 DDD(Domain-Driven Design)를 다시 펴 보는 이유는 명확하다.
도메인 모델은 인간이 이해하는 비즈니스 언어이고, AI 에이전트가 일하기 가장 좋은 표면이다. Axon Framework가 MCP(Model Context Protocol)를 네이티브 지원하기 시작한 것이 그 증거다 — agent-ready한 시스템은 결국 도메인이 잘 분리된 시스템이다.
그런데 DDD를 책 한 권으로만 이해한 개발자가 너무 많다. 사실 DDD는 세 명의 작가가 10년에 걸쳐 합작한 결과물이고, 그들의 입장은 부분적으로 충돌한다. 이 글은 그 충돌 지점을 정확히 보고, 그 위에 2026년의 액터·카프카·에이전트 시대가 어떻게 이어졌는지를 추적한다.
2. DDD 3인방 — 누가 무엇을 만들었나
인물 | 출판 | 기여 | 핵심 메시지 |
Eric Evans | 2003 "Domain-Driven Design" | 창시자 | 도메인 모델의 언어(유비쿼터스 언어), 애그리거트, 바운디드 컨텍스트 |
Vaughn Vernon | 2013 "Implementing Domain-Driven Design" (IDDD) | 구현 전파자 | 실제 코드/프레임워크로 구현하는 패턴, 작은 애그리거트, ID 참조 규칙 |
Greg Young | 2010 CodeBetter 글 + 강연 | 이벤트 소싱 + CQRS 창시자 | 상태가 아닌 사건 흐름으로 도메인 표현, 명령과 조회의 분리 |
사용자가 메모한 "에릭 영"은 그렉 영(Greg Young) 이다. 그가 CQRS 용어를 명명했고, 이벤트 소싱을 현대적 의미로 정립했다.
2.1 셋이 함께 만든 그림
- 에반스(2003): "도메인을 그대로 코드에 담아라. 객체 그래프가 그 자체로 비즈니스다."
- 버논(2013): "에반스의 그림을 실제로 구현하려면 이런 규칙이 필요하다 — 애그리거트는 작고, 트랜잭션 경계가 명확하고, 다른 애그리거트는 ID로만 연결하자."
- 영(2010~): "도메인의 진실은 마지막 상태가 아니라 그 상태에 도달한 사건의 흐름이다. 그리고 명령(쓰기)과 조회(읽기)는 다른 모델이다."
이 세 입장은 서로 다른 답이 아니라 다른 단계다. 그런데 가장 큰 오해는 §4에서 다룬다.
3. 자바 진영의 늦은 깨달음, POJO 운동의 등장
DDD가 등장하기 직전, 자바 진영은 EJB(Enterprise JavaBeans)의 무게에 짓눌려 있었다. 데이터는 EntityBean에, 로직은 SessionBean에 — 도메인이 둘로 쪼개진 anemic domain model이 표준처럼 굳어 있었다.
3.1 거의 동시다발로 일어난 4개 사건
시점 | 사건 | 의미 |
2000-09 | Martin Fowler · Rebecca Parsons · Josh MacKenzie가 POJO 용어 명명 | "왜 일반 객체를 안 쓰나? 멋진 이름이 없어서다" → 평범한 자바 객체에 가치를 돌려놓기 |
2002 | Rod Johnson "Expert One-on-One J2EE Design and Development" → Spring Framework 탄생 | EJB 거부, POJO 기반 엔터프라이즈 |
2003-11-25 | Martin Fowler "Anemic Domain Model" bliki anti-pattern 명시 | 데이터-only 객체는 OOP 위반이라고 못 박음 |
2003 | Eric Evans "Domain-Driven Design" 출판 | POJO 운동이 기다리던 이론적 골격 |
이 4개 사건은 사실상 같은 호흡이다. 자바 진영은 EJB의 잔재를 털어내며 POJO + 도메인 모델로 회귀하던 중이었고, DDD는 그 회귀에 이름과 체계를 줬다.
3.2 반 버논의 양안 경험
반 버논은 35년 이상의 경력에 자바와 C#을 모두 다룬 개발자다. 그의 IDDD 책은 자바 예제로 쓰였지만 C# 개발자에게도 적용 가능하도록 의도된 구조다. 이후 그는 VLINGO XOOM 플랫폼을 만들었고 — JVM 메인 + C# 포트 동시 운영이다.
사용자 메모의 표현은 "닷넷 진영에서 배워 자바로 옮겼다"였지만, 정확한 1차 출처로 단정하긴 어렵다. 분명한 사실은 다음이다.
- CQRS의 명명자 그렉 영은 .NET 진영에서 출발해 자바 진영에 영향을 줬다 (CodeBetter 2010).
- 반 버논은 두 진영의 어휘를 공유 가능한 형태로 풀어놓은 첫 저자다.
- 마틴 파울러가 그 흐름에 합류해 POJO + 도메인 모델로 자바 진영을 재구성했다.
자바 진영이 늦었다기보다는, 두 진영이 서로의 결론을 가져와 합친 시기라고 보는 것이 정확하다.
4. 가장 큰 오해 — 애그리거트 참조는 객체인가 ID인가
이 절은 본 글의 심장이다. "애그리거트는 다른 애그리거트를 ID로만 참조해야 한다" — 이 규칙은 반 버논 IDDD의 4대 가이드라인 중 하나이지, 에반스의 원본이 아니다.
4.1 에반스의 원본 입장 — 객체 참조 + Traversal
에반스 원본은 다음을 명시했다.
- 외부 객체는 루트만 참조한다. 다른 애그리거트의 내부 객체에는 직접 접근하지 않는다.
- 루트 내부의 객체는 root에서 traversal로 찾는다. 외부에서 직접 못 잡는다.
- DB 쿼리는 애그리거트 루트만 직접 조회 가능하다. 나머지는 association traversal.
여기서 핵심은 — 에반스는 "다른 애그리거트의 루트는 객체로 참조해도 된다"고 명시했다. 사용자 메모가 짚은 그대로다.
4.2 에반스가 객체 참조를 허용한 4가지 근거
- 객체지향 패러다임과의 자연스러운 매핑 — DDD는 OOP 기반이다. 도메인의 연관 관계는 곧 객체 포인터로 표현되는 게 자연스럽다.
- 연관 관계의 응집도와 표현력 — 객체 참조 = 응집도(cohesiveness), ID 조회 = 결합도 낮춤(decoupling). 둘을 적절히 조합해야 설계가 가장 이해하기 쉽다.
- DB 중심 설계로 변질 방지 — 모든 접근이 쿼리로 바뀌면 도메인 로직이 클라이언트와 쿼리 코드로 새어 나가고, 엔티티는 데이터 컨테이너로 전락한다.
- 객체 DB 시대의 배경 — 책을 쓰던 2003년 무렵에는 GemStone, Versant, db4o 같은 OODBMS가 RDB와 함께 활발히 고려됐다. 그 환경에서는 메모리상 객체 그래프 탐색이 가장 자연스러운 표현이었다.
다만 에반스 본인도 "모든 접근을 참조로만 해결하면 거미줄처럼 엉킨다"고 경고했다. 극단은 양쪽 다 위험하다.
4.3 반 버논의 ID 참조 규칙 — 4가지 근거
에반스 (2003) | 반 버논 IDDD (2013) |
외부에서 다른 애그리거트 루트는 객체로 참조 OK | ID로만 참조 |
Traversal과 검색을 조합 | 모든 애그리거트 간 연관은 식별자로 추론 |
객체 DB 시대 OOP 응집도 | Consistency boundary 분리 + 분산 환경 대비 |
- Consistency boundary 보존 — 참조된 애그리거트는 참조한 애그리거트의 일관성 경계 안에 들어오지 않는다.
- Performance/Scalability — 의존 객체는 명령 호출 전에 미리 조회해서 넘기는 게 낫다. 애그리거트에 repository나 도메인 서비스를 직접 주입하지 않는다.
- 분산 환경 대응 — 다른 애그리거트가 다른 노드에 있을 수 있다. 객체 참조는 분산에서 깨진다.
- 실용적 단순성 — 작은 애그리거트 + ID 참조 = 트랜잭션 경계 명확.
4.4 누가 옳은가 — 둘 다 맥락의 답이다
환경 | 에반스 쪽이 맞는 답 | 버논 쪽이 맞는 답 |
단일 프로세스, JPA, 작은 시스템 | 객체 참조 — JPA @ManyToOne이 자연스럽고 응집도 ↑ | — |
분산 마이크로서비스, 멀티 노드 | — | ID 참조 — 다른 노드의 엔티티를 객체로 잡을 수 없다 |
이벤트 소싱 + CQRS | — | ID 참조 — 이벤트는 항상 ID만 들고 흐른다 |
객체 그래프 deep traversal이 도메인의 본질 | 객체 참조 — 강제로 ID로 바꾸면 도메인이 데이터 모델에 종속됨 | — |
사용자 메모의 직관 — "JPA 쓰면서 연결을 ID로 바꿔 놓으면 짜치지 않나"는 정확히 에반스 쪽 응집도 논리다. 단일 프로세스 + JPA 환경에서 객체 참조가 더 자연스러운 것은 사실이다. 다만 그 시스템이 분산으로 진화할 가능성이 보이면, ID 참조로 미리 옮기는 게 마이그레이션 비용을 줄인다.
중립적 결론: 에반스 → 버논 → 영의 순서는 다른 답이 아니라 다른 환경의 답이다. OOP에서 분산으로, 분산에서 이벤트로, 환경이 바뀌며 답도 진화했다.
5. DDD 프레임워크의 세 갈래
DDD를 실제로 구현하는 프레임워크는 크게 세 갈래로 갈렸다.
5.1 액터 기반 — 반 버논의 또 다른 책
2015년 반 버논은 **"Reactive Messaging Patterns with the Actor Model"** (Addison-Wesley)를 출판했다. 부제는 "Applications and Integration in Scala and Akka".
액터 모델은 현대 엔터프라이즈에서 DDD를 구현하는 가장 자연스러운 방법이다.
이유는 명확하다.
- 액터 = 자체 상태 + 비동기 메시지. 이게 곧 애그리거트 + 도메인 이벤트다.
- 액터의 위치 투명성 = 분산 환경에서 ID 참조가 자연스럽다.
- 감독(supervision) = 도메인 실패 정책의 1급 표현.
이 흐름이 그의 VLINGO XOOM 플랫폼(JVM 메인, C# 포트)으로 이어졌다. 즉 Akka가 DDD 친화적인 게 아니라, 버논이 DDD를 액터 모델로 다시 풀어낸 결과가 Akka 진영 위에 얹혔다.
5.2 DDD 전용 프레임워크 — Axon Framework
Axon Framework는 JVM 진영의 명실상부 DDD/CQRS/Event Sourcing 전용 1위 툴킷이다.
- 70M+ 다운로드 (JVM 진영 최대 오픈소스 DDD 툴킷)
- 최신 메이저 (2026 시점): Async-Native API, 분산 saga 오케스트레이션, eventual consistency 보장 (v6 라인 — 정확한 GA 시점은 Axoniq 릴리즈 노트 참고)
- Axon Server: 분산 command bus + event bus + query bus + event store 한 묶음
- MCP 네이티브 지원 — agent-ready 시스템으로 진화
2026년 Axoniq 벤치마크에 따르면, event processor의 batch size를 1 → 500으로 올리면 replay rate가 260 events/sec → 4,000 events/sec로 약 15배 향상된다.
5.3 액터모델과 무관한 갈래 — Spring Modulith, Eventuate
- Spring Modulith (2022, VMware/Spring팀): Spring 진영에서 모듈 단위로 DDD 바운디드 컨텍스트를 표현.
@ApplicationModule어노테이션 + ApplicationEvent 기반 모듈 간 통신 + 의존 그래프 자동 검증(ApplicationModules.verify()). 마이크로서비스로 가기 전 단일 배포 단위에서 컨텍스트를 깔끔하게 분리하고 싶을 때 1순위.
- Eventuate Tram + Eventuate ES (Chris Richardson, Microservices Patterns 저자): Saga 오케스트레이션 + Transactional Outbox 패턴 1급 지원. Kafka/RabbitMQ 위에서 도메인 이벤트와 분산 트랜잭션을 함께 다룬다. Spring Boot/Quarkus와 자연스럽게 결합.
이들은 액터 모델을 안 쓰지만, 이벤트 소싱과 도메인 이벤트의 흐름은 공통이다. 결국 2026년의 자바 진영 DDD 선택은 "액터(Akka/VLINGO) vs 전용(Axon) vs 모듈러(Modulith) vs 사가 중심(Eventuate)"의 4갈래로 정리된다.
6. 카프카 전성시대 — 이벤트 소싱의 인프라 표준
그렉 영이 이벤트 소싱을 정립한 2010년대 초반에는 적당한 인프라가 없었다. 2020년대 들어 Apache Kafka가 이벤트 소싱의 인프라 표준으로 자리 잡았다.
6.1 카프카가 이벤트 소싱과 잘 맞는 이유
- Append-only 로그 — 이벤트 소싱의 기본 추상과 정확히 일치.
- Partition by aggregate ID — 같은 애그리거트의 이벤트는 같은 파티션에 순서 보존.
- Log compaction — 최신 스냅샷만 남기는 retention 정책. 무한 히스토리를 다루지 않고도 현재 상태 재구성 가능.
6.2 9가지 Kafka 디자인 패턴 (2025-12 arxiv 연구)
2025년 12월 arxiv에 발표된 분석 논문은 Kafka 기반 이벤트 스트리밍 시스템의 9가지 재현 패턴을 식별했다.
- Log compaction
- CQRS bus — 명령은 이벤트로 쓰고, 별도 컨슈머가 read model로 투영
- Exactly-once pipelines
- CDC (Change Data Capture) — Debezium으로 RDB 변경을 이벤트 스트림으로
- Stream-table joins
- Saga orchestrator — 분산 트랜잭션 흐름 제어
- Tiered storage
- Multi-tenant topics
- Event sourcing replay — 스냅샷 + 압축 + 보존 정책 조합
DDD 관점에서 특히 중요한 것은 CQRS bus, Saga orchestrator, Event sourcing replay 세 가지다. 이 셋이 결합되면 그렉 영의 모델이 카프카 위에서 그대로 살아 움직인다.
6.3 카프카가 풀지 못한 것 — DDD 전용 프레임워크가 위에 얹히는 이유
카프카는 "이벤트 백본"이지 "도메인 모델 표현 도구"가 아니다. 그래서 위에 다음이 올라간다.
- Axon Server + Axon Framework — Kafka의 위 레이어. 도메인 이벤트, 애그리거트, 사가를 1급 표현으로.
- Akka Persistence (+ Akka Cluster Sharding) — 액터 자체를 이벤트 저장소에 영구화 + 샤딩으로 분산.
- Eventuate Tram — Kafka의 위에 Outbox + Saga 패턴 보강.
즉 2026년의 표준 스택은:
[ 도메인 모델 표현 ] Axon / Akka / VLINGO ↓ [ 이벤트 백본 ] Kafka (+ Debezium CDC) ↓ [ 저장소 ] RDBMS, EventStoreDB, S3 tiered
7. AI 시대에 DDD가 살아남는 이유
다시 도입부 질문으로 돌아오자. 왜 지금 DDD인가.
답은 세 가지다.
- AI 에이전트는 도메인 언어를 가장 잘 이해한다. 유비쿼터스 언어가 잘 잡힌 시스템일수록 AI가 정확하게 일한다. Axon이 MCP를 네이티브로 단 것이 그 신호다.
- 이벤트 소싱은 AI에게 완벽한 학습 데이터다. 시스템의 모든 결정이 사건으로 남아 있다 — agent가 과거를 정확히 재현하고 분석할 수 있다.
- 액터 모델은 멀티 에이전트 아키텍처의 표준이 됐다. 1973년 Carl Hewitt의 액터가 2026년 AI 에이전트의 자연스러운 추상이 되리라곤 누구도 예측 못 했지만, 결국 거기로 수렴했다.
7.1 세 명의 작가, 세 갈래 길의 합
작가 | 시대의 답 | 2026년 의미 |
Eric Evans | 도메인 모델의 언어 | AI 에이전트가 일하는 표면 |
Vaughn Vernon | ID 참조 + 액터 모델 | 분산 멀티 에이전트 시스템의 기본형 |
Greg Young | CQRS + Event Sourcing | 카프카 + LLM 시대의 데이터 흐름 |
세 명의 합은 다른 답이 아니라 다른 단계다. 처음 DDD를 공부할 때 책 한 권으로 끝났다는 인상은 잘못된 것이다. 세 작가의 출판 시점차 10년 + 그 위에 액터·카프카·AI가 얹힌 23년이 합쳐서 지금의 DDD다.