5편. Micro Service는 도출하는 이벤트 스토밍에 대해서

Bounded Context 기반 도출

바운디드 컨텍스트란 DDD를 적용한 설계에서 비즈니스 응집성이 있는 도메인을 정의하고 도메인 간의 경계를 식별하는 단위를 의미한다.

 

이 바운디드 컨텍스트가 마이크로서비스를 식별하는데 좋은 단위로 사용된다.

 

우선, 하나의 큰 도메인을 전략적으로 중요도에 따라 나누어야 한다. 또한, 하나의 큰 도메인을 여러 개의 하위 서브 도메인으로 분리해야 한다.

 

이때, 똑같은 회원이더라도 예약 도메인에서의 회원과 결제 도메인에서의 회원은 의미가 다르다. 예약 도메인에서는 예약자의 개인정보를 가지고 있는 예약자의 역할, 결제 도메인에서는 결제자의 역할로 카드 정보 등을 가지고 있는 회원을 의미한다.

따라서, 각 바운디드 컨텍스트마다 같은 회원이더라도 각 컨텍스트에서 사용되는 언어로 표기해야 한다.

 

이런 식으로 도메인 모델들을 구성하다 보면 회원과 같이 여기저기서 사용하는 의미가 달라지게 된다. 이때 경계가 도메인의 경계인 바운디드 컨텍스트이다. 

 

내가 만든 Context Map에서 일부 Bounded Context 예시

이전에 상담 서비스의 MSA 프로젝트를 진행하면서 직접 작성했던 자료이다. 아직은 여기까지 설명하지는 않았지만 노란색 직사각형 포스트잇의 각 기능의 사용자를 잘 보면 된다.

 

첫 번째는 회원 컨텍스트이다. 회원 컨텍스트의 각 기능의 사용자는 상담 의뢰자와 전문가로 구성된다.

 

 

두 번째는 결제 컨텍스트이다. 해당 기능의 사용자는 상담 상품 구매자이다.

 

이렇듯, 각 컨텍스트마다 같은 회원이더라도 의뢰자, 상품 구매자 등으로 다양하게 용어가 사용되고, 이게 컨텍스트를 구분하는데 용이하다는 것이다.

 

 

Context Mapping을 통한 연결

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

하지만, 다른 컨텍스트와 의존관계를 낮춘다는 것은 쉬운 일이 아니다. 주문과 배송이라는 바운디드 컨텍스트가 존재할 때 동기 방식으로 처리하던지 비동기 방식으로 처리하던지 결국에는 의존관계가 생기기 마련이다.

 

이러한 의존관계를 컨텍스트 매핑이라고 한다. 그림으로 나타낼 때는 컨텍스트 간의 선으로 나타낸다.

 

컨텍스트 매핑의 관계로는 공유 커널, Cusotmer-Supplier, Anti-Corruption Layer와 같은 여러 가지 매핑 방법이 있다.

대표적으로 Customer-Supplier 매핑 전략에서는 공급자 컨텍스트를 상위에 두고, 소비자 컨텍스트를 하위에 두는 방식으로 연결한다.

 

이런 식으로, 하나의 큰 도메인을 여러 개의 바운디드 컨텍스트로 나누고 매핑 관계를 표현한 것을 Context Map이라고 부른다.

이때, 비동기 이벤트 기반 통신 방식과 동기 Rest API 기반 통신 방식 등을 표현해 주는 것이 좋다.

 

이벤트 스토밍을 하는 방법

이벤트 스토밍은 이벤트 중심으로 여러 이해관계자들(도메인 전문가, 기획자, 개발자, 디자이너 등)이 모여서 브레인스토밍을 하는 워크숍을 의미한다.

MSA 프로젝트를 진행하면서, 이러한 방식을 편하게 적용해 보고자 Figma를 이용해서 온라인으로 진행했던 적이 있었는데 값진 경험이었다.

 

현실의 비즈니스 도메인을 이벤트 스토밍에서 사용하는 다양한 의미의 포스트잇을 이용해서 그려내는 과정을 진행하는데 아래와 같은 순서로 대상을 식별해 내면 된다.

 

1. 도메인 이벤트 (주황)

비즈니스 프로세스에서 발생하는 이벤트를 과거형 통사로 작성한다.
이때, 이벤트는 왼쪽에서 오른쪽으로 시간 흐름순서로 붙이고, 만약 이벤트가 연쇄적으로 발생하는 경우는 바로 옆에 붙이도록 한다.
중요한 것은 시스템 화면을 생각하는 게 아니라 비즈니스를 구성하는 요소들의 상태가 어떻게 변경되는지에 집중해야 한다.

 

ex) 주문됨, 주문 취소됨

 

2. 외부 시스템 (핑크)

서드 파티 시스템과 같이 외부 시스템을 호출하거나 사용하는 것을 표시한다.
이벤트의 오른쪽 상단에 붙이고 화살표를 그려서 이 외부 시스템을 호출한다는 것을 표시하면 된다.

 

ex) 이메일 시스템, PG 결제 시스템, 금융결제원 시스템

이메일 시스템 핫핑크

3. 커맨드 (파랑)

각 도메인 이벤트를 동작하게 하는 커맨드를 찾으면 된다.
명령형으로 작성하면 되고, 도메인 이벤트의 좌측에 붙여준다.

주의해야 할 것은, 하나의 커맨드에 여러 개의 이벤트가 발생할 수 있다는 것이다.

 

ex) 로그인 (로그인됨의 커맨드)

 

4. 핫스팟 (보라)

워크숍 도중에 정할 수 없는 사항이거나 의문사항을 찾으면 표기한다.
각 커맨드 옆에 붙이면 된다.

 

ex) 주문 가능 조건 확인

 

5. 액터 (노랑 - 작은 포스트잇)

화면을 통해 커맨드를 유발할 수 있는 사용자(역할)를 표기한다.

추상적으로 작성하는 것이 아닌, 구체적인 실제로 수행하는 ex) 구매자, 배달기사 등등 명확한 역할을 도출해내야 한다.

커맨드의 왼쪽 아래에 붙이면 된다.

액터를 도출하면서는 식별한 커맨드와 이벤트를 하나의 문장으로 만들어서 검토해봐야 한다.

 

ex) 의뢰자가 상담을 예약하면 [상담예약됨]이라는 이벤트가 발생한다.

 

6. 애그리거트 정의 (노랑 - 큰 포스트잇)

커맨드와 도메인 이벤트가 벌어지는 것을 어떤 단어로 칭할 수 있을지를 애그리거트로 표현한다.

애그리거트도 액터와 마찬가지로 추상적이지 않게, 구체적인 표현으로 도출하는 것이 중요하다.
그 이유는 애그리거트를 구체적으로 식별할수록 컨텍스트의 경계를 식별하기 수월해진다.

커맨드와 도메인 이벤트의 중간 상단에 붙여준다.

 

ex) 회원, 상담, 결제

 

7. 바운디드 컨텍스트 그리기 (경계선)

애그리거트를 봤을 때 일부 애그리거트는 이름이 같거나 유사하다. 이런 경우, 이름이 같거나 유사한 애그리거트는 완전히 다른 애그리거트와 구분해서 경계를 그린다.

 

각 바운디드 컨텍스트에는 이름을 부여하고, 이 이름은 바운디드 컨텍스트 내의 애그리거트 이름으로 정의할 수 있다.

만약, 내부에 여러개의 애그리거트가 있다면 그중 루트 애그리거트 역할을 하는 것의 이름으로 정의한다.

 

바운디드 컨텍스트를 고려할 때 예시로, 구매 컨텍스트에서 주문, 결제, 주문 아이템이 애그리거트로 식별됐지만 모두 나누지 않고 하나의 컨텍스트로 설계할 수 있다. 왜냐하면 주문에서 결제까지 하나의 Flow로 이루어지기 때문에 각각을 분리하지 않고 구매 컨텍스트로 묶을 수 있다.

 

8. 비즈니스 정책 도출 (라일락)

이벤트 뒤에 따라오는 비지니스 로직으로, 어떠한 커맨드를 동작하게 만든다.

정의: [도메인 이벤트]할 때는 항상 [커맨드]한다.  

 

따라서, 정책은 도메인 이벤트와 커맨드 사이에 존재하며, 이러한 정책이 호출하는 커맨드는 같은 바운디드 또는 외부 바운디드 컨텍스트에 존재할 수 있다.
이러한 정책을 도출해내는 과정에서 여러 바운디드 컨텍스트 간의 관계를 식별해 낼 수 있다. 

 

ex) [상담 취소됨] -> 정책 [상담 상품 상태 변경] -> [상담 상품 상태 변경됨]

 

9. 컨텍스트 매핑

8번까지 진행하면 대략 바운디드 컨텍스트가 식별되고 관계가 파악되고 매핑을 하면 된다.

 

이때 중요한 것은, 호출 관계의 방향을 고려해야 하고, 동기 방식 또는 비동기 방식 중 어떤 방식의 호출이 필요한지 고려해야 한다.

이때, 컨텍스트 간에 항상 일관된 데이터가 필요한 관계일 때는 동기 호출로 표현하고, 결과적으로 일관성이 있으면 충분히 처리 가능한 관계라면 비동기 방식 호출로 표현한다.
하지만, 의존도를 낮추기 위해 정말 실시간으로 정합성이 맞아야 하는 경우만 아니라면 비동가 이벤트 처리 방식으로 구현하는 것이  좋다.
또한, 비동기 방식에서 사용하는 메시지 브로커의 성능과 안정성이 올라감에 따라 현재는 비동기 방식을 많이 사용한다.

• 동기 호출은 실선
• 비동기 호출은 점선

 

10. 결과물 확인

아래 사항을 체크해야 한다.

1. 비지니스 측면에서 하나의 맥락으로 구분되는가?
2. 데이터 측면에서 Micro Service별로 분리된 데이터를 정의 가능한가?
3. 운영 측면에서 독립적으로 운영 가능한가?
4. 변경 시 서로 영향도가 큰가?

 

그리고 이 이후에 상세 설계를 진행하게 된다.

프론트엔드와 백엔드 서비스로 나누어져 개발하므로, 백엔드에서는 서비스의 모델링과 개발 영역으로 구분되어 스프린트를 진행하게 된다.

 

백엔드 개발 부분에서 말하자면
마이크로서비스 애플리케이션을 헥사고날 아키텍처를 도입해서 애그리거트를 도메인 모델로 구현하고, 도메인 이벤트와 커맨드 등을 포트와 어댑터로 구현하면 된다. 또한, API는 프론트엔드와 협력하여 화면에서 필요로 하는 구성으로 설계해야 한다.

당연히, API를 사용하는 곳은 프론트엔드 화면 단이므로 화면에서의 요구사항에 전적으로 맞춰줘야 한다.