[DDD-Quickly] 5,6장 요약 정리 - 모델 무결성과 오늘날 DDD

이번 포스팅에서는 도메인 주도 설계(DDD) 책의 5장과 6장에 대해 정리하고, 그 과정에서 얻은 인사이트를 공유해 보려 합니다. 5장은 대규모 프로젝트에서 모델 무결성(내부 일관성, 통일성)을 지키기 위한 전략적 패턴과 기법을, 6장은 오늘날 DDD가 왜 더욱 중요해졌는지를 다룹니다.
두 장 모두 한층 더 “전략적인 관점”에서 DDD를 바라볼 수 있어서 개인적으로도 도움이 많이 되었습니다.

---

1. 분할된 컨텍스트 (Bounded Context)
   1) 컨텍스트의 개념
   • “용어가 특정 의미를 갖도록 보장되는 모델의 범위”를 말합니다.
   • 대규모 기업 시스템에서는 전체를 하나로 묶으려 하기보다, 서로 자연스럽게 묶이는 개념을 중심으로 모델을 쪼개어 관리하는 편이 모델 무결성 유지에 유리합니다.
   2) 분할된 컨텍스트 ≠ 모듈
   • 컨텍스트는 “논리적 프레임”으로, 해당 범위 안에서 일관된 도메인 언어와 모델을 운영합니다.
   • 모듈은 모델 내부를 조직화하는 방법으로, 코드 차원의 구조화(패키지·폴더 등)에 가깝습니다.
   → 예시: 전자상거래 시스템에서 “구매/주문 관리”와 “리포팅/메시징”을 별도의 모델(컨텍스트)로 분리해, 팀별로 독립적으로 작업하면서도 필요한 인터페이스만 딱 맞게 정의해 상호작용하게 할 수 있습니다.
2. 지속적인 통합 (Continuous Integration)
   • 여러 팀이 동일한 컨텍스트에서 개발할 경우, 모델이 제각각 흩어지기 쉽습니다.
   • 이를 방지하려면 자동화된 빌드·테스트 체계를 적용하고, 모델과 코드를 수시로 통합하는 습관을 들여야 합니다.
   • 분할된 컨텍스트 간에도 “정기적으로” 혹은 “사건이 있을 때” 상호작용 규칙이 올바른지 점검해야 합니다.
3. 컨텍스트 맵 (Context Map)
   • 대규모 애플리케이션에서 여러 컨텍스트와 그 관계를 한눈에 볼 수 있도록 표현한 “전체 지도”
   • 각 컨텍스트의 경계와 의존관계를 명시적으로 표현해, 프로젝트 전 구성원이 공유하고 이해하도록 합니다.
   • 중복 범위, 예상치 못한 충돌 지점을 발견하고 조정하는 데 큰 도움이 됩니다.
4. 컨텍스트 간 통합을 위한 주요 패턴들
   1) 공유 커널 (Shared Kernel)
   • 두 팀이 밀접하게 협력해야 할 때, “공동으로 사용해야 할 모델 일부”를 별도 모듈로 추출해 공유합니다.
   • 이 공유 부분은 양쪽 팀 모두 임의 변경 불가하며, 서로 의사소통하여 일관되게 진화시켜야 합니다.
   2) 고객-공급자 (Customer-Supplier)
   • 한 컨텍스트(공급자)가 다른 컨텍스트(고객)에게 필요한 기능·정보를 제공하는 관계
   • 공유 커널 없이, 공급자가 제공하는 인터페이스나 DB 스키마를 고객이 소비하는 구조입니다.
   • 고객 컨텍스트가 “요구사항”을 공급자에게 제시해 협의하고, 공급자는 그 규약을 지키는 방식으로 협업합니다.
   3) 변질 방지 레이어 (Anti-Corruption Layer)
   • 레거시나 외부 시스템과 상호작용할 때, “그쪽 모델을 그대로 받아들여 내 도메인을 오염시키지 않기” 위해 중간 계층을 둡니다.
   • 번역(매핑) 기능을 통해 우리 쪽 모델은 “깨끗하고 일관되게” 유지하고, 외부 모델과의 충돌이나 영향은 레이어가 책임집니다.
   4) 분할 방식 (Separate Ways)
   • 통합 자체가 큰 이점을 주지 못하거나, 유지 비용이 과도할 경우 아예 통합을 포기하고 독립적으로 운영합니다.
   • 예: 완전히 별도의 어플리케이션으로 관리, 서로 교집합을 거의 두지 않고 분산 시스템 형태로 개발.
   5) 오픈 호스트 서비스 (Open Host Service)
   • 여러 외부에서 내 시스템을 이용해야 할 때, 공용 프로토콜/서비스를 정의해 “공개”합니다.
   • 번역 레이어마다 따로 구현할 필요 없이 합의된 API나 프로토콜을 사용하는 식으로, 모든 공급자/소비자 간 통합을 단순화할 수 있습니다.
5. 증류 (Distillation)
   • 도메인이 큰 경우 핵심 영역(Core Domain)과 일반 서브 도메인을 구분해, 핵심에 집중하고 일반적인 부분은 별도 솔루션·아웃소싱 등을 고려합니다.
   • 제한된 자원을 핵심에만 몰아주어 설계 역량을 집중하고, 비핵심에는 적절한 수단을 택하는 전략이 중요합니다.

---

오늘날 DDD가 더욱 중요한 이유 (6장)

에릭 에반스의 인터뷰 요약을 통해, DDD의 필요성이 과거보다 더 커졌음을 알 수 있습니다.

1) 소프트웨어의 역할 확장

• 단순한 업무 자동화 수준을 넘어, 복잡한 비즈니스 로직과 도메인 고유의 문제 해결에 집중하는 시대입니다.
• 모델이 제대로 잡혀 있지 않으면, 비즈니스 요구사항을 구현 과정에서 제대로 반영하기 어렵습니다.

2) 기술 플랫폼 발전

• 자바, .NET, 루비 등의 웹/클라우드/마이크로서비스 플랫폼이 성숙해지면서, “도메인 모델을 유지하기에 좋은 구조”를 실현하기가 훨씬 수월해졌습니다.

3) 애자일 및 협업 문화 확산

• 애자일 프레임워크나 DevOps 문화가 퍼지면서, 도메인 전문가와 개발자가 밀접하게 협력하고 빠르게 피드백을 주고받는 환경이 조성되었습니다.
• DDD가 강조하는 상시적 대화, 지속적 통합, 모델 개선이 훨씬 자연스러워진 것입니다.

4) 실무에서의 조언

• 전체 도메인 모두에 DDD를 적용하려 애쓰기보다는, “핵심 도메인”을 잘 골라 DDD 기법을 집중 적용해 보는 전략이 좋습니다.
• 모델 리팩터링 과정에서 다양한 실험과 실패를 통해, 원하는 수준의 모델 완성도를 높여 가는 것이 중요하다고 합니다.

---

✍️ 마무리 정리

1. 분할된 컨텍스트를 통해 대규모 모델을 여러 팀이 각각 유지·관리할 수 있게 하고, 컨텍스트 맵으로 전체 그림을 공유합니다.
2. 지속적인 통합, 공유 커널, 고객-공급자, 변질 방지 레이어, 분할 방식, 오픈 호스트 서비스 등 다양한 패턴을 활용해 “서로 다른 컨텍스트”가 함께 동작하도록 조정합니다.
3. 핵심 모델(핵심 도메인)에 집중 투자하고, 일반적이며 복잡도가 낮은 부분은 외부 솔루션·아웃소싱·단순화 방식을 검토해 효율성을 높입니다.
4. 오늘날 비즈니스의 요구사항이 정교해지고, 협업 환경과 인프라가 개선됨에 따라 DDD의 효과가 더욱 극대화되고 있습니다.

책이 마무리되었는데 막연하게 DDD에 대해  크게 어려운 개념은 아니라고 생각했습니다. 하지만 생각보다 난이도가 있는 내용이고 단순하게 개발 방법론이라기 보다는 조금 더 상위의 개념이라고 느꼈고, DDD는 개발만 잘하면 되는 방법이 아닌, 여러 동료와 협업하면서 좋은 제품을 만들기 위한 지침이라고 생각됩니다. 잘 이해가 안됐던 부분들도 여러 번 읽다보니 완벽하게는 아니지만 개념적으로 이해된 것 같습니다. 실제로 프로젝트에 적용해보면서 핵심 도메인을 골라서 적용해보며 체감하고 추후에 다시 정리된 내용을 보는게 좋을 것 같다고 느꼈습니다.