🚀 도메인 주도 설계(DDD) 그 후 - 현재의 DDD는 어떻게 발전했는가?

📌 과거의 DDD vs 현재의 DDD

과거의 **도메인 주도 설계(DDD)**는 추상적인 개념과 철학적인 접근이 많았지만, 현재의 DDD는 보다 구체적이고 실용적인 형태로 발전했습니다.
특히, 도메인의 범위를 구체화하고 솔루션까지 포함하는 형태로 변화했습니다.

📌 현재의 DDD는 크게 두 가지 패턴으로 나뉩니다.
1️⃣ 전략적 패턴 (Strategic Patterns) → 비즈니스 문제 공간(Problem Space)에서 도메인을 분리하는 과정
2️⃣ 전술적 패턴 (Tactical Patterns) → 솔루션 공간(Solution Space)에서 도메인을 코드로 구체화하는 방법

💡 즉, 문제를 이상적으로 나누고(디스틸레이션), 실제 구현에서 바운디드 컨텍스트를 어떻게 적용할 것인지 고민하는 과정이 포함됨.

---

🔹 바운디드 컨텍스트와 디스틸레이션

📌 바운디드 컨텍스트 (Bounded Context)

• 솔루션 공간(Solution Space)에서 도메인 모델을 현실적으로 나누는 방법
• 하나의 도메인 모델이 모든 상황에 적합하지 않기 때문에, 팀별로 바운디드 컨텍스트를 나누어 운영

📌 디스틸레이션 (Distillation)

• 문제 공간(Problem Space)에서 핵심 도메인과 하위 도메인을 구분하는 과정
• 비즈니스적으로 핵심적인 도메인(코어 도메인)과 지원 도메인을 분리

💡 이 두 개념을 활용하면, 불필요한 도메인 복잡도를 줄이고 중요한 부분에 집중할 수 있음.

---

🔨 도메인 주도 설계 구현 - 반 버논(Vaughn Vernon)의 정리

📖 반 버논의 "Implementing Domain-Driven Design"에서 현재의 DDD 체계 정립

• 전술적 패턴과 전략적 패턴 개념을 확립
• 문제 공간(Problem Space)과 솔루션 공간(Solution Space) 개념을 도입
• 아키텍처와 구현에 대한 가이드 제공

---

🔗 DDD와 아키텍처 - 트랜잭션 관리 및 도메인 이벤트

📌 트랜잭션 당 하나의 애그리게이트

• 하나의 트랜잭션이 여러 애그리게이트를 수정하지 않도록 제한
• 예제:
  • Order(OrderLineItem)과 Customer가 별도의 트랜잭션을 가짐
  • 주문 수(Order Count)는 고객(Customer) 엔티티와 직접 연결되지 않음

📌 도메인 이벤트 (Domain Event) - Eric Evans

• 도메인 모델에서 발생한 중요한 사건을 기록하는 개념
• DB 상태 변경을 직접 감지하는 것이 아니라, 이벤트를 기반으로 다른 애그리게이트와 동기화
• 주문 생성(Order Created), 결제 완료(Payment Processed) 등의 이벤트 활용

---

🔄 이벤트 소싱 (Event Sourcing)

📌 데이터베이스(DB)에 최종 상태만 저장하는 것이 아니라, 변경 이력을 모두 기록하는 방식

💡 일반적인 DB는 다음과 같이 저장됨.

scss

복사편집

1 → 2 → 4 → 6 (최종 상태: 6만 저장)

📌 하지만, 변화 과정을 추적하려면?

• 이벤트 소싱을 활용하여 모든 변경 이력을 저장
• DB가 아니라 **이벤트 스토어(Event Store)**에 저장
• 이벤트 로그를 재생하면 데이터베이스 없이도 동일한 상태를 복구할 수 있음
• 실무에서는 성능 이슈로 완전히 이벤트 소싱만을 사용하는 것은 어려움

✅ 이벤트 소싱이 등장한 이유?

• 도메인 이벤트와 애그리게이트를 보다 효과적으로 관리하기 위해
• 비즈니스 흐름을 추적하고, 변경 사항을 명확하게 이해할 수 있도록 지원

---

⚖ CQRS - 복잡성 해결을 위한 도메인 모델 분리

💡 애그리게이트가 책임이 과도해지면?

• 애그리게이트는 수정(Write) 범위를 관리하는 개념이지, 조회(Read) 기능까지 포함하는 것은 적절하지 않음
• UI에서 데이터를 가져올 때 조회(쿼리)까지 애그리게이트가 담당하면 불필요한 복잡성이 증가

📌 CQRS(Command Query Responsibility Segregation)란?

• 조회 모델(Query Model)과 변경 모델(Command Model)을 분리하는 방식
• 일반적으로 읽기(Read)는 최적화된 쿼리 방식으로 빠르게 제공
• 쓰기(Write)는 도메인 모델을 통해 철저하게 검증

📌 CQRS 활용 예제

• 상품 데이터가 방대할 경우, 직접 JOIN해서 조회하면 성능 문제가 발생
• 해결 방법:
  • 데이터를 별도로 분리하고 Kafka 등의 메시지 큐를 활용하여 전송
  • 빠른 조회를 위해 별도의 캐시(Cache) 또는 검색 인덱스 활용

✅ 결과적으로, CQRS를 활용하면 복잡한 도메인 모델에서도 성능을 최적화할 수 있음.

---

🚀 DDD와 MSA (Microservices Architecture)의 연결

💡 DDD는 MSA(마이크로서비스 아키텍처)와 함께 성장했다!

• 2012년 이후 MSA가 유행하면서, 작은 서비스들의 결합이 하나의 응용 프로그램을 구성하는 방식으로 변화
• 바운디드 컨텍스트 개념이 MSA에서 핵심 개념으로 활용됨
• 각 마이크로서비스가 하나의 바운디드 컨텍스트로 동작하며, 서비스 간의 관계를 명확히 정의

✅ DDD는 MSA와 함께 시스템을 분리하는 방법론으로 자리 잡음!

---

🏗 핵사고날 아키텍처(Hexagonal Architecture)의 재조명

📖 2005년 등장한 "Hexagonal Architecture"

• 핵심 개념: UI나 DB에 의존하지 않는 독립적인 애플리케이션 설계
• 자동화된 테스트가 용이하고, 변경이 유연함
• 핵심 비즈니스 로직을 "핵심(Core)"으로 두고,
  입출력(Ports)과 외부 시스템(Adapters)을 별도로 분리

💡 하지만 DDD를 한다고 무조건 Hexagonal Architecture를 사용할 필요는 없음!

• 둘은 독립적인 개념이며,
• 프로젝트의 특성과 요구사항에 따라 적절한 아키텍처를 선택해야 함.

---

🏆 결론: 현재의 DDD는?

✅ 과거의 이론적 개념에서 벗어나, 실용적인 설계 및 구현 방법론으로 발전
✅ 바운디드 컨텍스트와 디스틸레이션을 활용하여 도메인 모델을 명확하게 분리
✅ 도메인 이벤트와 이벤트 소싱을 통해 데이터 변경을 추적하고, 안정성을 보장
✅ CQRS를 활용하여 복잡성을 해결하고, 성능을 최적화
✅ MSA 및 다양한 아키텍처 패턴과 함께 사용되며, 더욱 실용적인 개념으로 자리 잡음

💡 과거에는 "이론적인 철학"에 가까웠던 DDD가, 이제는 현실적으로 적용할 수 있는 실무 지침으로 변화하고 있습니다! 🚀

---