[마이크로서비스 아키텍처 구축] 챕터2. 마이크로서비스 모델링 방법

2.4 딱 도메인 주도 설계만큼

마이크로서비스 경계를 찾는 데 사용되는 기본 메커니즘은 도메인 주도 설계(DDD)이며, 이는 도메인 자체를 중심으로 진행한다.

DDD는 프로그램에서 문제 영역을 더 잘 표현하는 중요하는 개념들을 제시했다.

• 보편 언어
  • 의사소통을 돕기 위해 코드와 도메인 설명에 사용할 공통 언어를 정의하고 채택한다.
• 애그리거트
  • 객체들의 집합이며 일반적으로 실제 세계 개념과 관련된 하나의 개체로 관리된다.
• 경계 콘텍스트
  • 더 큰 범위의 시스템에 대한 기능을 제공하지만 복잡성을 숨기는 비즈니스 도메인 내부의 명시적인 경계.

2.4.1 보편 언어

보편 언어란 사용자가 쓰는 용어를 코드에서 동일하게 사용하려고 노력해야 한다는 것이다.

• 용어가 통용되는 곳? 코드! 코드에는 동일하게 사용되는 용어가 없기 때문이다.
• 없었을 때 발생되는 문제? 구축 중인 시스템을 코드베이스에서 이해하지 못할 정도로 코드를 오염시켰다!

2.4.2 애그리거트

DDD에서 다소 혼동되는 개념이자 다양한 정의가 존재한다. 애그리거트는 시스템의 일부로 관리될 상태, 고유함(identity), 수명주기를 가진 것으로 실제 세계의 개념을 나타낸다.

 

위의 예에서 Order Aggregate에는 Order, DeliveryInfo, PaymentInfo라는 Entity가 있고, Order Entity는 OrderLineItem(메뉴별 주문량)이라는 VO와 연결됩니다. Order와 OrderLineItem은 1:N의 관계가 됩니다. Aggregate는 고유의 비즈니스 목적 수행을 위한 데이터 객체들의 집합이다.

하나의 마이크로서비스는 하나 이상의 서로 다른 종류의 애그리거트에 대한 수명주기와 데이터 저장소를 처리한다. 다른 서비스의 기능이 애그리거트 중 하나를 변경하려는 경우, 해당 애그리거트에 직접 변경을 요청하거나 애그리거트 스스로 시스템의 다른 구성 요소와 상호작용해서 상태 전환이 이뤄지도록 해야 하며, 예를 들면 다른 마이크로서비스에서 발행한 이벤트를 구독함으로써 가능하다.

애그리거트 간의 관계가 하나의 마이크로서비스 범위 내에 존재할 때 관계형 데이터베이스를 사용한다면 외래 키 관계와 같은 것을 이용해 쉽게 저장할 수 있다. 하지만 이러한 애그리거트 간의 관계가 마이크로서비스 경계를 넘어 걸쳐 있다면 관계를 모델링할 방법이 필요하다.

이 방식의 장점은 두 가지다. 관계의 특성이 명시적이며 REST 시스템에서는 이 URI를 직접 역참조해 관련 자원을 조회할 수 있다.

2.4.3 경계 콘텍스트

경계 콘텍스트는 일반적으로 보다 큰 구조적 경계(organizational boundary)를 나타낸다. 그 경계의 범위 내에서는 명시적인 책임을 수행할 필요가 있다.

• 특징
  • 구현 세부 사항을 숨긴다. 내부에서만 고려하면 되는 사항도 있다 (예를 들어 창고 외부의 사람들은 어떤 종류의 지게차가 사용되는지에 전혀 관심 없다.)
  • 구현 관점에서 애그리거트를 하나 이상 포함한다. 일부 애그리거트는 경계 콘텍스트 외부에 노출될 수 있고, 어떤 것들은 내부에 숨겨져 있을 것이다. 애그리거트와 마찬가지로 경계 콘텍스트 사이에도 관계가 존재할 수 있다. 서비스에 매핑될 때 이러한 종속성은 서비스 간의 종속성이 된다.
• 도메인
  • 우리가 운영하는 전체 비즈니스를 말한다. 창고부터 접수 데스크까지, 재무에서 시작해 주문에 이르기까지 모든 것을 다룬다.
• 은닉 모델
  • ex) 뮤지코프의 경우 재무 부서와 창고를 2개의 독립된 경계 콘텍스트로 간주할 수 있다.
• 공유 모델
  • ex) 기업 가치를 계산하려면 재무 직원이 보유한 재고에 대한 정보가 필요하다. 따라서 재고 품목은 두 콘텍스트 간 공유 모델이 된다.
  • 그림 2-15) 공유 모델은 외부와 공유해서는 안 되는 정보를 숨길 수 있다.
  • 재고 품목과 같은 공유 모델은 서로 다른 경계 콘텍스트에서 다른 의미를 가질 수 있어 다른 이름으로 불릴 수 있다.

2.4.4 애그리거트와 경계 콘텍스트를 마이크로서비스에 매핑

• 애그리거트와 경계 콘텍스트는 외부의 더 넓은 시스템과 상호작용하기 위해 잘 정의된 인터페이스로, 응집력의 단위를 제공한다.
• 둘 다 서비스 경계로 잘 작동할 수 있다. 처음에 언급했듯이 여러분은 작업하는 서비스의 수를 줄이길 원하며, 결과적으로는 전체 경계 콘텍스트를 포괄하는 서비스를 대상으로 삼아야 할 것이다.

거북이 아래 거북이

• 처음에는 아마도 여러 개의 큰 경계 콘텍스트를 인지하겠지만, 이러한 경계 콘텍스트는 결과적으로 더 많은 경계 콘텍스트를 포함할 수 있다. 예를 들어, 창고를 주문 이행, 재고 관리, 제품 수령과 연관된 기능으로 분해하는 방식이 그렇다.
• 심지어 나중에 전체 경계 콘텍스트를 모델링하는 서비스를 더 작은 서비스로 분해하기로 결정했더라도, 소비자에게 보다 큰 단위의 API를 제공하는 방식으로 이 결정을 여전히 외부 세계에 숨길 수 있는 기법이 존재한다.
• 그림 2-16) 창고 서비스는 내부적으로 재고와 배송 마이크로서비스로 분리됐다.

2.4.5 이벤트 스토밍

• 정의
  • 도메인 모델을 표면화하도록 설계된 협력적인 브레인스토밍 훈련으로, 아키텍트가 한 구석에서 홀로 고민하며 도메인 모델에 대한 표현을 찾아내는 대신에 기술 전문가와 비전문가가 다 같이 참여하는 공동 작업을 의미함.
• 물류
  • 진행방식의 핵심은 모든 이해관계자가 동시에 참석하는 것이다.
• 프로세스
  • 연습은 참가자가 도메인 이벤트를 식별하는 것에서 시작한다. 이벤트는 주황색.

• 다음으로 참가자는 이러한 이벤트를 발생시키는 명령을 식별한다. 명령 = 무언가 하려고 내리는 결정, 시스템의 핵심이 되는 사람 (액터)를 식별한다. 명령은 파란색 쪽지.

• 이벤트와 명령이 캡처되면 애그리거트가 그다음이다.

2.5 마이크로서비스를 위한 도메인 주도 설계 사례

• 장점
  • DDD의 경계 콘텍스트가 정보 은닉에 명시적으로 사용되는데, 이는 안정적인 마이크로서비스 경계를 찾는 데 매우 중요하다.
  • 공통적인 보편 언어를 정의하는 데 중점을 두는 것은 마이크로서비스 엔드포인트를 정의할 때 큰 도움이 된다.
  • 시스템에 대한 변경은 비즈니스가 시스템의 작동 방식을 변경하려는 경우가 많다. 변경해야 할 곳이 줄어들어 신속하게 변경 사항을 배포할 수 있다.
  • 비즈니스 도메인을 소프트웨어의 중심에 둠으로써 소프트웨어 개발자들의 도메인 전문성이 향상된다. 게다가 소프트웨어 사용자에 대한 이해와 공감대를 형성하고 기술 제공, 제품 개발, 사용자 사이에서 의사소통도 증대된다.

2.6 비즈니스 도메인 경계에 대한 대안

DDD가 MSA 구축할 때 유용하긴 하지만, DDD 말고도 다른 여러 방법을 같이 사용하는 경우가 많다.

2.6.1 변동성

• 시스템에서 더 빈번하게 변경되는 부분을 식별한 다음 해당 기능을 자체 서비스로 추출해 더 효과적으로 작업 가능하다.
• 이를 적용한 예시는 바이모달 IT이다. 바이모달 IT는 다양한 시스템이 얼마나 빠르거나 느리게 수행돼야 하는지에 따라 ‘모드 1’ (기록 시스템), ‘모드 2’ (혁신 시스템)로 분류한다. 모드 1은 많이 변경되지 않고 비즈니스와 크게 관련이 없다. 반면 모드 2는 신속하게 변경해야 하고 비즈니스와 밀접하게 관련돼야 하는 시스템을 위한 곳이다.
• 하지만 필자는 이러한 단순한 모델을 추천하진 않는다고 한다. 다만, 시장 출시 기간을 단축하는 데 매우 유용하다고 한다.

2.6.2 데이터

• 필자의 최근 고객인 페이먼트코라는 결제 전문 기업의 경우 특정한 종류의 데이터를 사용하므로 시스템을 분해하는 결정에 직접적인 영향을 받았다.
• PCI 표준에서 설정한 다양한 요구 사항을 준수해야 한다. 이러한 규정의 일환으로 기업의 시스템과 프로세스는 감사를 받아야 한다. 페이먼트코는 전체 신용카드 데이터를 처리해야 했고 시스템은 PCI 레벨 1을 준수해야 했다. 이 레벨은 가장 엄격한 수준이며 데이터 관리 방식과 관련된 시스템 및 관행에 대한 분기별 외부 평가가 필요하다.
• 그림 2-17) 페이먼트코는 PCI 요구 사항의 범위를 제한하려고 신용카드 정보 사용 여부에 따라 프로세스를 분리한다.

2.6.3 기술

• 실행 중인 단일 마이크로서비스에서 서로 다른 데이터베이스를 수용할 수 있지만, 서로 다른 런타임 모델을 혼합하려는 경우, 문제에 직면할 수 있다.

2.6.4 조직

• 소유권이 여러 팀에 걸쳐 분리돼 있는 서비스에 대한 경계를 정의하려 한다면 바라는 결과를 얻지 못할 것이다.
• 어떤 상황에서는 원하는 아키텍처를 이루기 위해 조직 구조의 변경을 고려해야 할 수도 있다.

2.7 혼합 모델과 예외

• 정보 은닉의 지침을 따르고 결합과 응집력의 상호작용을 이해한다면 어떤 메커니즘을 선택하든 최악의 함정을 피할 수 있다. 이러한 개념들에 중점을 둔다면 도메인 주도 아키텍처가 될 가능성이 더 높다고 생각한다.
• 더 깊이 탐구하려면, 반 버논의 '도메인 주도 설계 구현(2016, 에이콘)'을 추천한다!