개요
MSA와 함께 대두되고 있는 설계, DDD에 대해 얘기합니다. DDD에 대해서 알고 있지만 실제 코드 레벨에선 어려운 점들이 있어 도움을 받고자 합니다.
DDD에 대한 오해
- DDD는 빌딩 블록, 전술적 설계(패턴)에 함몰됩니다. 사실 DDD의 본질인 전략적 설계에 집중해야 합니다.
- DDD는 작은 서비스나, 비즈니스 도메인이 약한 서비스에는 어울리지 않습니다.
- DDD와 MSA는 시너지가 날 수도 있지만, 아닐수도 있습니다.
- 방법론 같은게 아닌 추상적인 접근법입니다.
전략적 설계
- 만약 패스트티켓 회사라면 현실 세계의 티켓팅의 인터넷 예매을 소프트웨어 세계에서 해결할 문제 도메인으로 추출합니다.
- 이를 하위(서브) 도메인으로 나누기도 합니다.
- 도메인 지식 기반에서 유비쿼터스 언어를 통한 지속적인 의사소통을 통해 현업으로부터 문제를 이해하게 됩니다. 이 과정을 ‘지식 탐구’라고 합니다.
- 여기서 핵심은 예매입니다.
- 문제 공간에서는 현업, 해결 공간에서는 개발자가 주가 됩니다.
- 시간이 점점 지나고 기능이 추가되면 복잡해집니다.
- Big ball of mud는 안티 패턴이 아닙니다. 여기서 잘 쪼갤 때 필요한게 이벤트 스토밍입니다.
- 전략적 설계 vs 전술적 설계
- 범위는 전반적 vs 특정 바운디드 컨텍스트
- 목적은 문제 도메인을 해결 영역으로 vs 풍부한 도메인 모델 적용
- 전쟁에 전략, 전투에서 전술
- 바운디드 컨텍스트, 유비쿼터스 랭기쥐, 애그리것, 도메인 이벤트
- 접근법 vs 방법론
Bounded-Context
- 경계가 있는 문맥을 말합니다.
- 모델이 모호해질 수 있지만 바운디드 컨텍스트로 묶으면 모델의 모호함이 사라지고 무결성이 생깁니다.
- 콘웨이 법칙 → 소프트웨어의 구조는 해당 소프트웨어를 개발하는 조직의 구조를 따라간다는 법칙입니다.
- 따라서 개발 조직의 구조를 소프트웨어의 구조에 맞추는 것이 좋습니다. → 역콘웨이의 전략