개요

마이크로 서비스를 어떻게 도출할까?
그리고 MSA 와 DDD 는 어떤 연관이 있을까?

마이크로 서비스는 다른 서비스와 의존하지 않게 독립적인 형태로 도출되어야 합니다.
다음 두 도출 방식이 있습니다.

• 비즈니스 능력에 근거한 도출
• DDD 의 바운디드 컨텍스트 기반 도출

비즈니스 능력에 근거한 도출

마이크로 서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것입니다.
각 도메인에서는 비즈니스가 규정하는 일하는 방식과 조직, 부서 체계가 이미 정의돼 있고, 이러한 부서는 이미 업무 처리에서의 응집성을 지니며 타 부서와 의존도는 낮을 것입니다.

업무 기능 분해 : 비즈니스 부서가 가진 역할, 처리 능력을 체계적으로 분해

업무 기능을 분해하고 수행하는 일들을 체계적으로 정렬하면 특정 부서가 처리하는 업무 역할과 비슷해집니다. 이를 기반으로 직관적으로 서비스를 식별할 수 있습니다.

이 방식은 전체적인 대략의 비즈니스를 이해할 때는 유용합니다.
하지만 서비스 간의 관계 파악, 서비스의 구체 기능과 연관된 서비스가 관리할 독립적인 데이터를 식별하기에는 미흡합니다.

DDD 의 바운디드 컨텍스트 기반 도출

마이크로 서비스는 각 저장소를 독립적으로 보유하고 다른 서비스의 데이터를 직접 참조해서는 안됩니다.
따라서 마이크로 서비스를 도출할 때 소유권을 가진 데이터를 독립적으로 식별하는 것이 중요합니다.
(서비스가 보유한 기능에 의해서만 접근 가능한(캡슐화) 데이터를 파악해야 합니다)

DDD 는 데이터를 기능과 분리해서 식별하지 않고 문제 영역인 하위 도메인마다 별도의 도메인 모델로 정의합니다.
(분리된 도메인 모델에 의해 다른 컨텍스트와 구별되는 경계를 바운디드 컨텍스트라 합니다)
이러한 특성이 독립적인 팀이 자율적으로 마이크로 서비스를 개발 및 운영하는 MSA 개념과 매우 잘 어울립니다.

DDD 설계

DDD 전략적 설계에서는 비즈니스 응집성이 있는 컨텍스트를 구분하고, 이를 바운디드 컨텍스트라 하는데 이 단위가 마이크로 서비스를 식별하기 위한 훌륭한 단위가 될 수 있습니다. 또한 전략적 설계를 통해 식별된 마이크로 서비스의 내부 구조를 정의하고 상세히 설계하기 위해 DDD 의 객체 설계 기법인 전술적 설계를 사용할 수 있습니다.

전략적 설계

전략적 설계는 마이크로 서비스를 도출하는 방법입니다.
또한 비즈니스상 전략적으로 중요한 것을 찾아 중요도에 따라 일을 나누기 위해 사용할 수 있습니다.
DDD 에서는 하나의 큰 도메인을 (전략적으로 중요한 것들을 찾아) 중요도에 따라 도메인을 나누고, 각 도메인을 각각 하나씩 해결하는 방법을 기본으로 삼습니다.
이러한 방법을 위한 몇 가지 개념을 소개합니다.

• 도메인과 서브도메인
  비즈니스 도메인을 (논리적으로 구분하여) 여러 개로 분리한 하위 도메인을 서브 도메인이라고 합니다.
  (이렇게 나누면 문제가 되는 영역을 쉽게 이해할 수 있습니다)

  
  

  서브 도메인은 중요도에 따라 세 가지 유형으로 나뉩니다.

  • 핵심 서브도메인
    프로젝트 목록에서 높은 우선순위를 갖는 영역
  • 지원 서브도메인
    비즈니스에 필수지만 핵심은 아닌 부분
  • 일반 서브도메인
    비즈니스적으로 특화된 부분은 아니지만 전체 솔루션에는 필요한 부분

• 유비쿼터스 언어
  각자가 사용하는 말이 달라 바벨탑 건축이 실패했듯이, 우리 프로젝트에서도 고객, 현업 담당자, 개발자, 기획자 들이 사용하는 기술 언어가 일관적이지 못할 때가 많습니다.

  
  

  유비쿼터스 언어는 특정 프로젝트에서만 사용하는 단어/용어 사전과 같은 역할을 합니다.
  (같은 단어라 해도 특정 상황(맥락)에 따라 의미가 달라질 수 있기 때문입니다)
  유비쿼터스 언어를 정의해서 이해관계자 모구 공통의 언어를 사용하면 용어에 따른 오해를 없앨 수 있습니다.

  유비쿼터스 언어는 예전 데이터 모델링에서 사용했던 표준 단어/용어 사전과는 다른 개념입니다.
  표준 단어/용어는 특정 프로젝트에서 하향식으로 규정됐던 개념이었다면, 유비쿼터스 언어는 그보다 작은 단위의 세부 도메인에 특정 업무와 관련된 사람들 간에 자율적으로 정의되고 통용되는 개념을 나타냅니다.

  유비쿼터스 언어는 특정 도메인의 업무 개념을 표현합니다.
  예를들면, 결제 도메인에서의 고객과 배송 도메인에서 고객은 의미가 다릅니다.

  • 결제 도메인에서는 상품 결제하는 역할에서의 고객(결제자)
  • 배송 도메인에서는 배송받는 역할(수취자)를 의미합니다.

  따라서 이러한 개념을 고객으로 포괄적으로 표현해서는 안 됩니다.
  각각의 도메인 맥락에 따라 명확하게 모델링 해야 합니다.

• 도메인 모델과 바운디드 컨텍스트
  도메인 모델은 특정 비즈니스 맥락에서 통용되는 개념들의 관계를 잘 정의한 모형입니다. 도메인 모델을 보면 해당 비즈니스를 이해할 수 있어야 합니다.

  
  

  새로운 팀원이 오더라도 소스코드에 존재하는 도메인 모델을 이해하고 이 모델로 도메인 전문가와 무리 없이 의사소통할 수 있다면 서비스는 지속적으로 민첩하게 개발/유지될 수 있습니다.
  (이러한 특성이 DDD 와 MSA 가 잘 어울리는 점입니다)

  
  

  이렇게 도메인 모델을 구성하다 보면 모델 간의 경계가 나누어집니다.
  이러한 도메인 간 경계를 바운디드 컨텍스트라 합니다.

  • 개념들을 원으로 묶어 표시 (원 안에 도메인 모델을 표현합니다)

  
  

  바운디드 컨텍스트를 식별할 때 각 컨텍스트는 내부적으로 응집력이 높고, 다른 컨텍스트와는 의존관계가 낮아야 한다는 원칙하에 설계합니다.

• 컨텍스트 매핑
  하나의 큰 도메인을 여러 개의 바운디드 컨텍스트로 식별하면 비즈니스 수행을 위해 여러 개의 컨텍스트가 연계해야 하는 경우가 발생합니다. 이러한 컨텍스트 간의 의존관계를 컨텍스트 매핑이라 합니다.
  • 연관관계에 있는 두 컨텍스트를 선으로 그어 표시

• 컨텍스트 맵
  하나의 큰 도메인을 여러 개의 바운디드 컨텍스트로 식별하고 아들 간의 매핑 관계를 표시한 다이어그램을 컨텍스트 맵이라 합니다.

  
  

  다양한 컨텍스트 매핑 패턴이 있습니다.

  • 공유 커널 (Shared Kernel)
    바운디드 컨텍스트 사이에 공통적인 모델을 공유하는 관계 (공통 라이브러리 등)
    • 단점 : 공유 부분이 변경되면 여러 관련 컨텍스트에 영향을 미침
    

    그림 3 - 공유 커널 (출처)

  
  

  • 소비자와 공급자 (Customer-Supplier)
    • 공급자는 상류 Upstream(U), 소비자는 하류 Downstream(D) 로 표시
    • 데이터 흐름은 상류에서 하류로 흐릅니다. (반대 흐름 불가)
    • 공급자는 소비자가 원하는 기능을 제공합니다.
    • (cf: 공급자가 소비자의 요구를 지원하지 못하는 경우에는 준수자(Confirmist) 패턴을 사용합니다)
    

    그림 4 - 소비자와 공급자 (출처)

  
  

  • 충돌 방지 계층 (ACL; Anti-Corruption Layer)
    하류팀이 상류팀의 모델에 영향을 받을 때 하류 팀의 고유 모델을 지키기 위해 번역 계층을 만드는 것입니다.
    • ACL 은 둘 사이 차이를 번역 (하류 모델의 독립성 유지)
    • MSA 를 적용하는 새로운 시스템을 기존 레거시 시스템과 통합하기 위해 주로 사용
      (MSA 점진적 전환 방식에 많이 사용)
    

    그림 5 - 충돌 방지 계층 (출처)

  
  

  • 공개 호스트 서비스 (OHS; Open Host Service)
    바운디드 컨텍스트에 대한 접근을 제공하는 프로토콜이나 인터페이스를 정의합니다.
    • 상위 컨텍스트에서 제공하는 기능을 용이하게 사용할 수 있도록 공개 (공유된 API 등)
    

    그림 6 - 공개 호스트 서비스 (출처)

  
  

  • 발행된 언어 (PL; Published Language)
    하류 컨텍스트가 상류에서 제공하는 기능을 사용하게 하기 위한 간단한 사용과 번역을 가능케 하는 문서화된 정보 교환 언어입니다.
    • XML, JSON 스키마로 표현
    • 주로 공개 호스트 서비스와 짝을 이뤄 사용
    

    그림 7 - 발행된 언어 (출처)

  
  
  

  컨텍스트 맵의 예제입니다.

  

  그림 8 - 중요도에 따른 컨텍스트 매핑 관계
  • 핵심 서브도메인이 동작하기 위해 지원 서브도메인과 일반 서브도메인의 정보를 활용합니다.
  • 지원 서브도메인 역시 동작을 위해 일반 서브 도메인을 활용합니다.
  • 세 컨텍스트가 공급자/소비자 관계를 맺고 있습니다.
  • 일반 서브도메인은 공개된 프로토콜/인터페이스(OHS), 발행된 언어(PL)를 제공합니다.
  • 핵심 서브도메인은 받은 정보를 번역(ACL)하여 사용합니다.

  
  
  

  조금더 구체적으로 매핑 유형을 표현해 보겠습니다.

  

  그림 9 - 컨텍스트 맵 사례
  • 회원, 제품, 주문, 배달, 배달지 컨텍스트 매핑 관계입니다.
  • 공급자 컨텍스트들은 HTTP/JSON 기반의 REST API 를 통해 동기 통신의 서비스를 제공합니다.
  • 점선으로 표시된 비동기 이벤트 메시지 발행을 볼 수 있습니다.