비즈니스 도메인을 중심으로 서비스를 모델링하면 마이크로서비스 아키텍처에 엄청난 장점이 생긴다. 문제는 이 모델을 구현하는 방법인데, 여기서 도메인 주도 설계(DDD)가 등장한다.
집계
도메인 주도 설계에서 집계는 다소 혼란스러운 개념이며, 다양한 정의가 존재한다. 이 책에서는 집계를 실제 도메인 개념의 표현으로 간주하는 모델로 사용했다고 한다. 주문, 송장, 재고 물품 등과 같은 요소를 예로 들 수 있다. 집계는 일반적으로 수명주기가 있으므로 상태 머신으로 구현할 수 있다. 집계를 독립된 단위로 취급하길 원하고 집계의 상태 전이를 처리하는 코드와 상태 자체를 함께 그룹으로 묶기를 원한다.
단일 마이크로서비스는 하나 이상의 다양한 집계의 수명 주기와 데이터 저장소를 처리한다. 다른 서비스의 기능이 이와 같은 집계 중 하나를 변경하려는 경우, 해당 집계의 변경을 직접 요청하거나, 집계 자체를 시스템의 다른 구성 요소에 반응시켜서 시스템 자체의 상태 전환을 개시해야 한다.
집계는 다른 집계와 관련 있을 수도 있다. 관련 있는 집계들을 별도로 모델링하고 각각 다른 서비스에서 처리할 수 있다.
시스템을 집게로 분해하는 방법은 많으며, 몇몇 선택은 주관적이다. 시간이 지나면, 성능상의 이유 또는 구현의 편의를 위해 집계를 재구성할 수도 있다. 그러나 첫 시작 때는 구현 문제를 제외하고 생각하고 다른 요소가 작동할 때까지 사용자의 요구 사항을 초기 설계에 대한 지침으로 삼는다.
경계 컨텍스트
경계 컨텍스트는 일반적으로 조직 내부의 더 큰 조직적인 경계를 나타낸다.(집계보다는 조금 더 큰 경계를 나타낸다는 의미 같다.) 해당 경계 내에서 명시적인 책임이 수행돼야 한다. 구체적인 예를 들어본다.
뮤직 사에서 창고는 주문 배송 관리, 새로운 재고 수취, 지게차 트럭들의 분주한 이동 등이 일어나는 활동의 중심이다. 재무 부서는 급여 처리, 선적 비용 지불 등의 중요한 기능을 수행한다.
경계 컨텍스트는 구현 세부사항을 숨긴다. 여기에는 내부적으로 고려할 사항이 있는 것이다. 예를 들어, 어떤 종류의 지게차가 쓰이는지는 창고 직원 이외의 다른 사람에게는 거의 관심을 끌지 못한다. 이런 내부적인 고려사항은 외부 세계로부터 숨겨져 있어야 마땅하다.
구현 관점에서 경계 컨텍스트는 집계를 하나 이상 포함한다. 입루 집계들은 경계 컨텍스트 외부로 공개될 수도 있으며, 또 다른 집계들은 내부적으로 숨겨져 있을지 모른다. 집게와 마찬가지로, 경계 컨텍스트는 다른 경계 컨텍스트와 서로 관계가 있을 수도 있다. 서비스에 매핑될 때 이런 종속성은 서비스 간 종속성이 된다.
집계와 경계 컨텍스트를 마이크로서비스에 매핑
집계와 경계 컨텍스트는 외부의 더 넓은 시스템과 상호작용하기 위해 잘 정의된 인터페이스로 응집력의 단위를 제공한다. 집계는 우리 시스템에서 단일 도메인 개념에 중점을 둔 독자적인 시스템으로, 관련된 집계의 집합을 표현하는 경계 컨텍스트와 함께 여기서도 더 넓은 세계에 대한 명시적인 인터페이스를 제공한다.
따라서 집계와 경계 컨텍스트 모두 서비스 경계로 작동할 수 있다. 서비스를 더 작은 서비스로 분해하기로 결정하게 되면, 집계 경계를 중심으로 분할하는 방법을 모색하면 된다. 서비스를 더 작은 서비스로 분해하는 결정은 구현 결정이 될 가능성이 높으므로, 가능하다면 숨기는 편이 좋을 수 있다.
