Bounded�Context�(Domain�Driven�Design)
아꿈사�
Cecil
도메인�모델의�근본적�요구사항�
비즈니스�규칙의�무결성을�제공�
규칙은�모호하지�않고,�모순이�없어야�함
이상적인�세계라면?�
전체�도메인�내에�단일화된�모델이�존재�
(ex:�회원)
회원
결제
카탈로그�
배송
주문
하지만,�현실�세계에서는..
배송지결제�수단
관심�항목 고객�등급
단일화된�모델을�유지하는것은�효과적이지�못하거나,�불가능
복잡함
그렇다면..�
단일화�할�것과,�그렇지�않은�것의�
명확한�구분이�필요
바운디드�컨텍스트�(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)
즉,�단일�모델을�각각의�컨텍스트로�분리
출처:�http://martinfowler.com/bliki/BoundedContext.html
도메인,�서브�도메인,��
바운디드�컨텍스트
도메인,�서브�도메인
소프트웨어가�해결해야할�문제�영역�
도메인은�서브�도메인으로�나누어짐�
(세부�업무�영역�or�조직의�구성..)
바운디드�컨텍스트
도메인의�문제를�해결(솔루션�영역)하기�위한��
도메인�모델이�존재하는�명시적인�경계
바운디드�컨텍스트와�서브�도메인은�
1:1�관계가�되는�것이�이상적.�
But,�그렇지�않은�경우가�많음.
추가적으로,�팀과�컨텍스트의�관계�역시�1:1이�이상적
모델을�명확히�했으니,�다음은??�
컨텍스트�간�연동을�위한�
명확한�정의가�필요
컨텍스트�맵�(Context�Map)
컨텍스트�간�상호�교류해야�하는�목록�및�방법을�명시
컨텍스트간의�관계(1/3)
•공유�커널(shared�kernel)�
•밀접하게�연관된�기능을�개발하는�경우�모델의�일부분을�공유�
•공유하는�모델의�부분�집합을�명시하고,�이�부분은�협의�없이�변경�금지�
•고객/공급자(Customer/supplier�Development)�
•한�시스템이�다른�시스템으로�데이터를�제공하는�경우�
•공급자�코드�테스트를�위한�자동화�테스트를�만들고,�CI�를�수행
컨텍스트간의�관계(2/3)
•부패�방지�계층(Anticorruption�Layer)�
•고객/공급자�관계에서�의사�소통이�적절하지�않는�경우�
•고객�측에서�자신의�도메인�모델에�맞게�변환하는�계층을�도입�
•오픈�호스트�서비스(Open�Host�Service)�
•다수의�고객에게�서비스를�제공해야�하는�경우�
•프로토콜을�정의하고,�단순하고�일관되게�유지
컨텍스트간의�관계(3/3)
•발행된�언어(Published�Language)�
•둘�사이의�오가는�데이터가�번역�자체가�복잡할�경우�
•적절히�문서화된�공유�언어를�사용하여,�각자가�독립적으로�해석�
•분리된�방법(Separate�Ways)�
•통합에�높은�비용이�들고,�기능�집합�사이에�유의미한�관계가�없을�경우�
•완전히�분리하여�각자의�기능을�개발
모델의�무결성�유지를�위한�패턴
References•Eric�Evans,�Domain�Driven�Design(이대엽�옮김).�
경기도�파주시�문발로�위키북스,�2011.��
•Vaughn�Vernon,�IMPLEMENTING�DOMAIN-
DRIVEN�DESIGN(윤창석,황예진�옮김).�서울시�양천구�
에이콘출판주식회사,�2016�
•최범균.�DDD�START!�도메인�주도�설계�구현과�핵심�
개념�익히기.�서울시�마포구�(주)지앤선,�2016.
Recommended
