1.
Bounded Context
(Domain Driven Design)
아꿈사
Cecil

2.
도메인 모델의 근본적 요구사항
비즈니스 규칙의 무결성을 제공
규칙은 모호하지 않고, 모순이 없어야 함

3.
이상적인 세계라면?
전체 도메인 내에 단일화된 모델이 존재
(ex: 회원)

4.
회원
결제
카탈로그
배송
주문
하지만, 현실 세계에서는..
배송지결제 수단
관심 항목 고객 등급
단일화된 모델을 유지하는것은 효과적이지 못하거나, 불가능
복잡함

5.
그렇다면..
단일화 할 것과, 그렇지 않은 것의
명확한 구분이 필요

6.
바운디드 컨텍스트
(Bounded Context)
The delimited applicability of a particular model.
BOUNDING CONTEXTS gives team members a
clear and shared understanding of what has to be
consistent and what can develop independently.
DDD community
(http://dddcommunity.org)

7.
즉, 단일 모델을 각각의 컨텍스트로 분리
출처: http://martinfowler.com/bliki/BoundedContext.html

8.
도메인, 서브 도메인,
바운디드 컨텍스트

9.
도메인, 서브 도메인
소프트웨어가 해결해야할 문제 영역
도메인은 서브 도메인으로 나누어짐
(세부 업무 영역 or 조직의 구성..)

10.
바운디드 컨텍스트
도메인의 문제를 해결(솔루션 영역)하기 위한
도메인 모델이 존재하는 명시적인 경계

11.
바운디드 컨텍스트와 서브 도메인은
1:1 관계가 되는 것이 이상적.
But, 그렇지 않은 경우가 많음.
추가적으로, 팀과 컨텍스트의 관계 역시 1:1이 이상적

12.
모델을 명확히 했으니, 다음은??
컨텍스트 간 연동을 위한
명확한 정의가 필요

13.
컨텍스트 맵
(Context Map)
컨텍스트 간 상호 교류해야 하는 목록 및 방법을 명시

14.
컨텍스트간의 관계(1/3)
•공유 커널(shared kernel)
•밀접하게 연관된 기능을 개발하는 경우 모델의 일부분을 공유
•공유하는 모델의 부분 집합을 명시하고, 이 부분은 협의 없이 변경 금지
•고객/공급자(Customer/supplier Development)
•한 시스템이 다른 시스템으로 데이터를 제공하는 경우
•공급자 코드 테스트를 위한 자동화 테스트를 만들고, CI 를 수행

15.
컨텍스트간의 관계(2/3)
•부패 방지 계층(Anticorruption Layer)
•고객/공급자 관계에서 의사 소통이 적절하지 않는 경우
•고객 측에서 자신의 도메인 모델에 맞게 변환하는 계층을 도입
•오픈 호스트 서비스(Open Host Service)
•다수의 고객에게 서비스를 제공해야 하는 경우
•프로토콜을 정의하고, 단순하고 일관되게 유지

16.
컨텍스트간의 관계(3/3)
•발행된 언어(Published Language)
•둘 사이의 오가는 데이터가 번역 자체가 복잡할 경우
•적절히 문서화된 공유 언어를 사용하여, 각자가 독립적으로 해석
•분리된 방법(Separate Ways)
•통합에 높은 비용이 들고, 기능 집합 사이에 유의미한 관계가 없을 경우
•완전히 분리하여 각자의 기능을 개발

17.
모델의 무결성 유지를 위한 패턴

18.
References
•Eric Evans, Domain Driven Design(이대엽 옮김).
경기도 파주시 문발로 위키북스, 2011.
•Vaughn Vernon, IMPLEMENTING DOMAIN-
DRIVEN DESIGN(윤창석,황예진 옮김). 서울시 양천구
에이콘출판주식회사, 2016
•최범균. DDD START! 도메인 주도 설계 구현과 핵심
개념 익히기. 서울시 마포구 (주)지앤선, 2016.