마이크로서비스 모델링 ③ : DDD의 전략적 설계

마이크로서비스 모델링 ③ : DDD의 전략적 설계

이번 포스팅에서는 마이크로서비스 도출의 유용한 기법으로 활용하고 있는 DDD의 전략적 설계 개념에 대해 좀더 자세히 알아보자 ___

유비쿼터스 언어 와 도메인 모델, 컨텍스트 경계

전라도 사투리로 ‘거시기’라는 용어가 있다. 이 ‘거시기’라는 용어는 신기하게도 어떠한 상황에서 그 상황에 참여하는 사람들간의 암묵적인 동의에 따라 그 의미가 공유되고 통용되곤 한다. 여기서 우린 언어의 특정한 특성을 파악할 수 있는데 언어라는 것은 이러한 같은 단어, 용어라 해도 특정 문화, 상황(맥락)에 따라 의미가 다르게 규정될 수 있다는 것이다.

DDD에서는 이렇게 특정 도메인에서 그 맥락에 따라 의미가 규정되는 단어,용어를 유비쿼터스 언어라 한다. 흔히 예전에 데이터 모델링에서 사용했던 표준 단어/용어 사전과는 다른 개념이다. 표준 단어/용어는 특정 프로젝트 , 전체 시스템에서 하향식으로 규정되었던 개념이었다면 유비쿼터스 용어는 그 보다 작은 단위의 세부 도메인에 그 업무를 같이 수행하는 사람들간에 정의되고 통용되는 개념들이다.

즉 유비쿼터스언어는 특정 도메인의 업무 개념을 표현하는 언어이다. 예를 들면 결제도메인에서의 고객과 배송도메인에서 고객은 그 의미가 틀리다. 결제도메인에서는 결제업무를 요청하는 역할에서의 고객 즉 지불자의 특성, 즉 지불자가 가지고 있는 지불카드정보, 계좌정보등이 중요하게 되고 배송도메인에서는 배송을 요청하고 상품을 받는 역할, 즉 수취인의 정보, 수취자 전화번호, 주소 등의 중요하게 된다.

따라서 이러한 개념은 고객으로 포괄적으로 그려져 표현되어서는 안된다. 명확하게 결제서비스에서 지불자의 개념으로 배송서비스에서 수취자의 개념으로 모델링되어야 한다. 그래야지 의존관계가 줄어든다.

아래 그림과 같이 이러한 도메인 특화 개념이 유비쿼터스 언어로 정의되고 이 개념들은 서로 관계를 가진다. 이런 관계를 표현한 모델을 도메인 모델(Domain Model) 이라 한다.

도메인 모델은 특정 비지니스 맥락에서 통용되는 개념들의 관계를 잘 정의한 모형이다. 도메인 모델을 보면 그 특정 비지니스를 이해할 수 있어야 한다. 이렇게 도메인 모델들을 구성하다 보면, 당연히 각 도메인 모델과 다른 도메인 모델간의 경계가 보인다. 여기서 사용하는 언어와 저곳에서 상용하는 언어와 개념이 상이하는 이 경계가 도메인의 경계, 컨텍스트 경계(Bounded Context)¹이다. 컨텍스트 경계는 원으로 표현하고 위의 그림처럼 그 원안에 도메인 모델을 표현할 수 있다.

이런 도메인 모델은 도메인에 함께 업무를 수행하는 제품 책임자, 도메인전문가 및 개발자를 포함한 모든 구성원들의 업무 이해의 기본 모형이 된다. 같은 컨텍스트를 다루는 이해관계자들은 도메인 모델에 정의된 언어로 업무 협의를 진행하고 개념을 발전시켜 나간다 . 또한 이 모델의 언어 그대로 설계 산출물에 표현하고 개발소스코드에도 사용된다. 따라서 예전 방식에서 설계 산출물에 사용했던 언어가 소스코드로 구현되면서 단축어로 사용됐던 방식을 지양한다. 설계 따로 개발 따로 이해를 위해 표준 용어 사전을 참조해야 했던 관행을 지양한다. 하나의 도메인에서 사용되는 유비쿼터스 언어는 팀의 의사소통 및 실제 동작하는 코드에서도 살아 숨숴야 한다.

새로운 팀원이 오더라도 소스코드에 존재하는 도메인 모델을 이해하고 이 모델로 도메인 전문가와 무리없이 의사 소통할 수 있다면 도메인과 서비스에 대한 동일한 비전을 공유할 수 있고 서비스는 지속적으로 민첩하게 개발, 유지 될 수 있다. 이러한 점이 DDD의 개념이 마이크로서비스의 개념과 잘 어울리는 점이다.

컨텍스트 매핑

각각의 컨텍스트 경계는 내부적으로 응집성이 높고, 다른 컨텍스트 경계와 의존관계가 낮아야 한다. 그렇지만 아무런 관계가 없지는 않다. 이런 컨텍스트간의 의존관계를 DDD에서는 컨텍스트 매핑 이라고 부르고 이러한 컨텍스트간의 다양한 관계 패턴을 설명하고 있다.

주요 컨텍스트 매핑 관계들

공유커널(Shared Kernel)

공유커널은 컨텍스트 경계 사이에 공통적인 모델을 공유하는 관계이다. 공유커널은 두개 이상의 팀에서 작지만 공통의 모델을 공유하는 관계를 나타낸다. 각 팀은 공유하는 모델에 서로 합의해야 한다. 보통 공통 라이브러리등이 될 수 있는데 이 부분이 변경되며 여러 관련 컨텍스트에 영향을 미치므로 공유하는 모델의 코드 빌드를 관리하고 테스트하는 것은 한 팀에 맡아 수행하도록 해야 한다.

수요자와 공급자(Customer-Supplier)

공급하는 컨텍스트는 상류(Upstream)로 수요자 되는 컨텍스트는 하류(Downstream)로 표시한다. 데이터의 흐름은 상류에서 하류로 흐른다. 반대는 가능하지 않기에 상류의 변화가 있으면 하류에서 변화를 따라야 한다.

충돌방지계층

충돌 방지 계층(Anti-Corruption Layer )은 하류 팀이 상류 팀의 모델에 영향을 받을 때 하류 팀의 고유 모델을 지키기 위한 번역 계층을 만드는 것이다. 이 계층은 둘 사이의 차이를 번역하며 하류 모델의 독립성을 유지시킨다.

공개 호스트 서비스

공개 호스트 서비스(Open Host Service)로 컨텍스트 경계에 대한 접근을 제공하는 프로토콜이나 인터페이스를 정의한다. 이 프로토콜은 하류가 용이하게 사용할 수 있도록 공개되어 있다. 보통 다른 컨텍스트에서 사용할 수 있는 공유된 API가 된다.

발행된 언어

발행된 언어(Published Language)는 공개 호스트 서비스와 짝을 이루는데 간단한 사용과 번역을 가능하게 하는 잘 문서화된 정보교환언어이다. XML이나 JSON스키마로 표현될 수 있다.

컨텍스트 맵

컨텍스트 경계를 식별해 내고 이들간의 관계를 표현한 그림을 컨텍스트 맵(Context Map)이라 한다. 위에서 언급한 여러 매핑 관계들로 작성할 수 있는데 아래는 간단한 컨텍스트 맵 의 예시이다.

위의 그림을 간단히 설명하면 일반서브도메인이 핵심서브도메인, 지원 서브 도메인과 공급자/수요자 관계를 가지고 있으며 일반서브도메인이 공개 호스팅 서비스로 발행된 언어를 다른 컨텍스트에 제공하고 있다. 또한 하류의 두개의 컨텍스트는 충돌방지 계층을 통해 상류의 모델을 번역하여 하류에서 사용할 수 있다. 위와 같이 전략적 설계 이후에 도출된 컨텍스트 기반으로 컨텍스트 매핑 관계를 이용하여 개념적인 컨텍스트 맵을 작성할 수 있으나 아직 구체적인 제공 기술 등이 정의되지 않은 상태를 설명하기 위한 용도이다.

매핑 구현 방안들이 좀 더 구체화되면 상류-> 하류로 데이터를 전달하기 위해SOAP이나 http 프로토콜 , 전달형태로써 XML,JSON , 동기 API나 비동기 이벤트를 이용하게 된다. 따라서 어느정도 맹핑 구현방안들이 정의되면 컨텍스트 맵이 아래와 같이 구체적으로 표현 될 수 있다.

위 그림을 보면 사용자,계정,장바구니,주문,재고의 컨텍스트 매핑 관계를 보여주고 있으며 공급자 컨텍스트들은 HTTP/JSON 기반의 REST API통해 동기 통신의 서비스를 제공하고 있고 사용자 컨텍스트는 계정 컨텍스트로 주문컨텍스트는 재고 컨텍스트로 각각 비동기 이벤트 메시지를 발행한다.

• 마이크로서비스 모델링 ① : 애자일 프로세스에서의 마이크로서비스 설계/개발 공정
• 마이크로서비스 모델링 ② : 마이크로서비스 도출기법
• 마이크로서비스 모델링 ③ : DDD의 전략적 설계
• 마이크로서비스 모델링 ④ : 이벤트 스토밍을 통한 마이크로서비스 도출
• 마이크로서비스 모델링 ⑤ : FrontEnd 설계
• 마이크로서비스 모델링 ⑥ : BackEnd 설계 - API설계
• 마이크로서비스 모델링 ⑦ : BackEnd 설계 - 도메인모델링

1. 분리된 도메인 모델의 의해 다른 컨텍스트와 구별되는 경계를 ‘컨텍스트 경계’라 부른다. ↩