🏗 도메인 주도 설계(DDD) - 파트4 전략적 설계

🎯 개발과 정치가 만나는 곳: 전략적 설계

소프트웨어 개발은 단순한 코드 작성이 아니라 조직의 구조, 협업 방식, 그리고 비즈니스 목표와도 맞물려 있는 전략적인 작업입니다.
특히, 대규모 시스템에서는 여러 개의 도메인 모델을 다루는 것이 핵심이 됩니다.

💡 전사(기업 전체)에 하나의 도메인 모델만 존재해야 할 필요는 없다!

• 팀마다 도메인 모델이 다를 수 있음
• 모든 도메인 모델이 중요한 것은 아니며, 중요한 곳에 집중해야 함

---

❌ 실무에서 마주하는 문제들

소프트웨어가 성장하면서 자연스럽게 복잡성이 증가하게 됩니다.

🔹 응집도가 낮은 코드

• 여러 팀이 함께 수정하다 보면 한 기능이 여러 도메인에 걸쳐 중복
• 유지보수가 어려워짐

🔹 기능 추가 & 코드 수정 시 충돌

• 단일 도메인 모델을 사용할 경우, 수정 시 예상치 못한 사이드 이펙트 발생
• 코드 변경이 다른 팀에 영향을 미치는 문제 발생

🔹 협업 오버헤드 증가

• 서로 다른 팀이 하나의 코드베이스에서 작업할 경우, 릴리즈 일정 조율 필요
• 다른 팀의 코드 변경이 나에게도 영향을 미칠 수 있음

📌 예제: 주문 도메인과 회원 도메인 충돌

• 회원 정보를 수정했는데 주문 도메인에서 버그 발생
• 주문 팀과 회원 팀이 조율해야 하는 불필요한 협업 증가

💡 ➡ 해결책: 코드 분리 & 바운디드 컨텍스트(Bounded Context) 적용

---

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

바운디드 컨텍스트란?
📌 특정한 도메인 모델이 적용되는 범위

🔹 왜 필요할까?

• 하나의 도메인 모델만 사용하면 사이드 이펙트가 커지고 협업 오버헤드가 증가
• 따라서, 각 팀이 독립적인 도메인 모델을 가져야 함
• 같은 개념이라도 각 컨텍스트마다 다른 의미를 가질 수 있음

🔹 예제: 전자상거래 시스템

1️⃣ 판매 컨텍스트의 상품(Product)

• 판매자는 상품을 등록하며, 상품 정보가 마케팅에 최적화됨
  2️⃣ 배송 컨텍스트의 상품(Product)
• 배송팀은 상품을 패키징하고, 물류 데이터를 관리

✅ 같은 "상품"이라도, 판매 컨텍스트와 배송 컨텍스트에서 다르게 해석될 수 있음!
→ 각 컨텍스트별로 별도의 도메인 모델을 사용해야 함

💡 Best Practice

• DB까지 분리하는 것이 가장 이상적
• MSA(Microservices Architecture)에서도 많이 사용됨

---

🔗 컨텍스트 맵 (Context Map)

📌 컨텍스트 사이의 관계와 모델 변환 방식을 정의하는 지도

🔹 컨텍스트 맵이 필요한 이유

• 팀 간 협업을 원활하게 하기 위해
• 다른 바운디드 컨텍스트로 데이터를 전달할 때 변환 방식 정의

🔹 예제

• 판매 컨텍스트에서 "상품" 데이터 → 배송 컨텍스트의 "상품" 데이터로 변환
• 각 컨텍스트가 독립적으로 동작하면서도 필요한 부분만 공유하도록 설계

🔹 조직 구조와의 관계

바운디드 컨텍스트는 단순한 코드 분리가 아니라 조직 관리 및 협업 방식과도 연결됨

• 각 컨텍스트는 팀 단위로 관리
• 팀 간 협업 방식 정리 필요

✅ 컨텍스트 간 협업 방식 3가지 1️⃣ 오너십을 가진 팀이 주도

• 한 팀이 전체 도메인을 주도 (ex. 주문 도메인이 데이터를 관리하고, 다른 팀이 이 데이터를 소비)
  2️⃣ Shared Kernel (공유 커널)
• 핵심 모델을 일부 공유 (ex. 회원 정보는 공통으로 사용)
  3️⃣ Conformist (종속적 관계)
• 한 팀이 다른 팀의 모델에 맞춰야 함

💡 ➡ 전략적으로 팀과 컨텍스트를 분리해야 유지보수성이 높아짐

---

🎯 전략적 디스틸레이션 (Strategic Distillation)

모든 도메인이 동일하게 중요한 것은 아니다!
→ 가장 중요한 도메인에 최고의 인력과 리소스를 집중해야 함

🔹 핵심 도메인(Core Domain)

• 비즈니스 성공에 결정적인 역할을 하는 도메인
• 가장 중요한 부분이며, 계속해서 변화하고 최적화되어야 함
• ✅ 최고의 개발자를 배정

🔹 지원 서브도메인(Supporting Subdomain)

• 코어 도메인을 지원하는 역할
• 예: 결제 시스템 (핵심 도메인이지만, 주문 시스템보다 상대적으로 후순위)
• ✅ 일반적인 개발팀이 관리

🔹 제너릭 서브도메인(Generic Subdomain)

• 경쟁 우위를 제공하지 않으며, 기성 소프트웨어로 대체 가능
• 예: 이메일 발송 시스템, 로그 시스템
• ✅ 주니어 개발자 배정 or 기성 솔루션 사용

📌 전략적 디스틸레이션의 핵심 1️⃣ 핵심 도메인(Core Domain)에 최고의 인력 집중
2️⃣ 덜 중요한 도메인은 외부 솔루션 도입 or 주니어 개발자가 담당
3️⃣ 전체적인 SW 비전을 잃지 않도록 명확한 우선순위 설정

---

🏆 결론: DDD의 전략적 설계를 적용하면?

💡 기술적인 분리가 아니라, 비즈니스와 조직 구조까지 고려해야 한다!

✅ 단일 도메인 모델이 아니라, 여러 개의 바운디드 컨텍스트를 도입해야 한다
✅ 컨텍스트 맵을 활용하여 팀 간 협업을 원활하게 해야 한다
✅ 핵심 도메인에 최고의 인력을 집중하고, 덜 중요한 도메인은 외부 솔루션으로 대체 가능

📌 DDD의 전략적 설계는 단순한 코드 분리가 아니라, 조직 운영 방식까지 고려해야 하는 중요한 개념입니다.
📌 결국, 도메인 모델은 비즈니스 전략과 함께 진화해야 합니다! 🚀