CH09 도메인 모델과 바운디드 컨텍스트
Last updated
Last updated
하나의 도메인은 여러 하위 도메인으로 구분된다. 그래서 여러 도메인을 공통적으로 만족시키는 도메인은 존재하기가 어렵고 각 도메인에 맞는 각 모델이 존재할 수 밖에 없다.
사용자 하나를 두고 보아도 회원 도메인에서는 회원이고 배송 도메인에서는 발송인, 보내는 사람 등이 될 것이다. 주문 도메인에서는 관심사가 주문을 누가 했는지이므로 주문자가 될 것이다. 이렇게 실제 동일한 대상 하나를 두고도 여러 하위 도메인에서 지칭하는 용어가 다르고 관심사가 다르다.
결국 특정한 모델은 특정한 문맥 하에서 완전한 의미를 갖는데 이 특정한 문맥을 컨텍스트라고 부르며 문맥간에 서로 경계를 갖는 문맥을 '바운디드 컨텍스트' 라고 한다.
다음은 DDD 세레나데 강의자료에서 바운디드 컨텍스트에 관한 내용이다.
하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다.
하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.
모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다.
이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT라고 부른다.
책에서도 말하고 있는데 이상적으로 하위 도메인과 바운디드 컨텍스트가 일대일 관계가 되면 좋지만 현실적으로 그렇지 않을 때가 많다. 용어를 구분하기 힘들수도 있고, 규모가 작은 기업에서 현실적인 여건으로 인해서 하나의 바운디드 컨텍스트로 두 개 이상의 도메인을 처리해야할 경우도 있다.
비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구현해야한다. 이렇게 함으로써 하위 도메인을 위한 모델이 서로 뒤섞이지 않고 하위 도메인마다 바운디드 컨텍스트를 갖는 효과를 낼 수 있다.
예를 들어 사용자가 회원에서는 Member로 애그리거트 루트이지만 주문에서는 Orderer 로 VALUE 가 된다.
바운디드 컨텍스트는 어떤 식으로든 연결되기 때문에 두 바운디드 컨텍스트는 다양한 방식으로 관계를 맺는다. REST API를 통해서 직접 관계를 맺는 방식도 있고 바운디드 컨텍스트 사이에 큐를 두고 큐에 A 컨텍스트가 데이터를 제공하고 B가 이를 구독하는 방식으로도 관계를 맺을 수 있다.
