DDD의 중요개념 중 하나인 바운디드 컨텍스트는 비즈니스에서 동일한 단어가 가리키는 대상이 여럿이 될 때 비로소 필요한 개념이다. 마틴 파울러의 블로그에 그 맥락이 잘 드러나 있다.
다시말해 하나의 단어가 가리키는 대상이 자명히 하나라면 필요가 없는 개념이 바운디드 컨텍스트라는 사실을 배울 수 있다. 처음에 본인들도 “전사적으로 단 하나의(1개의 단어가 유일한 의미를 가지는) 모델을 만들어라”라고 권장하다가, 풀고자 하는 문제가 광범위해질수록 그 방식이 효율적이지 않음을 깨달았다고 한다. 대부분의 경우 나는 하나의 단어가 의미하는 대상에 미묘한 다의성(polysemy)가 없는 경우를 모델링하며, 심지어 혼자 개발한다. 프로젝트가 풀고자 하는 문제가 충분히 커지고 복잡해진 경우 바운디드 컨텍스트 개념을 떠올려도 늦지 않다.
자 이제 하나의 바운디드 컨텍스트에서 개발을 하다가, 점점 프로젝트가 커지는 상황을 생각해 보자. 각 컨텍스트 내에서 같은 이름의 개념(예: "Customer")이 서로 다른 의미를 가져도 충돌 없이 발전시킬 수 있어야 한다.
src/
├── domain/
├── application/
└── infrastructure/
README.md
Bash
복사
프로젝트 스캐폴드에 이 개념이 고스란히 반영된다. 처음에는 단일 컨텍스트로 시작했더라도, 도메인이 복잡해지면서 서로 다른 의미를 가진 개념들이 등장할 때 스캐폴드에서도 가장 바깥쪽 경계를 만드는 방식으로 자연스럽게 확장된다.
src/
├── user-management/ # 사용자 관리 바운디드 컨텍스트
│ ├── domain/
│ ├── application/
│ └── infrastructure/
├── order-processing/ # 주문 처리 바운디드 컨텍스트
│ ├── domain/
│ ├── application/
│ └── infrastructure/
├── inventory/ # 재고 관리 바운디드 컨텍스트
│ ├── domain/
│ ├── application/
│ └── infrastructure/
└── shared/ # 공통 모듈: 여러 컨텍스트에서 공통으로 사용되는 도메인 개념은 shared_kernel 모듈에 배치하여 코드 중복을 방지하기도 함(https://github.com/qu3vipon/python-ddd)
README.md
Plain Text
복사
src/ 또는 프로젝트명/ 하위에 넣는 방식
user-management/ # 독립된 서비스
order-processing/ # 독립된 서비스
inventory/ # 독립된 서비스
shared-libraries/ # 공통 라이브러리
Plain Text
복사
각각을 독립된 저장소로 만들거나, 루트 자식으로 배치하는 방식
이렇게 하면 각각의 바운디드 컨텍스트 및 유비쿼터스 언어가 독립된 팀에 의해 관리되어야 한다는 원칙도 지키기 쉬워지고, 각각을 MSA(마이크로서비스 아키텍처) 등의 아키텍처로 분리해 확장하기도 쉬우며, 독립적으로 배포하고 버전 관리하기도 좋다.
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.
1.
None
from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.
1.
•
DDD를 적용하려다 보면 수많은 단어들에 압도당하는 기분이 들기도 한다. 개인 수준의 소형 프로젝트에 있어 가장 먼저 덜어낼 수 있는 개념은 바운디드 컨텍스트이다. 다행히 여러 개의 바운디드 컨텍스트를 고려해 작성된 스캐폴드만 벗겨 내도 한결 가벼워진다. 바운디드 컨텍스트 개념이 있거나 없거나 DDD + 클린 아키텍처를 프로젝트에 적용할 수 있다.
2.
•
이 프롬프트에 있던 불필요한 바운디드 컨텍스트를 제거했다.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.
1.
None
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.
1.
None
ref : 생각에 참고한 자료입니다.