마이크로서비스 모델링 ④ : 이벤트 스토밍을 통한 마이크로서비스 도출
Updated:
마이크로서비스 모델링 ④ : 이벤트 스토밍을 통한 마이크로서비스 도출
이전 포스팅을 통해 DDD의 전략적 설계의 주요 개념은 이해했지만 그 설계 과정은 아직 모호할 것이다.특히 마이크로서비스간의 의존성을 줄이기 위해서는 아키텍처 영역에서 언급했다시피 서비스 간 비동기 메시지 기반 도메인 이벤트를 활용하는 것이 중요한데 이러한 도메인 이벤트를 통한 의존관계 식별 방법이 용이하지 않다.
이에 Alberto Brandolini라는 이탈리아 출신 DDD컨설턴트가 DDD설계를 가속화 시킬 수 있는 설계 기법을 고안해 냈는데 이벤트 중심으로 이해 관계자들이 모여 브레인 스토밍 (Brain Storming)하는 워크샵이라 하여 이벤트 스토밍(Event Storming)이라고 부른다.
특히 이벤트 스토밍은 모든 이해관계자가 모여 서로가 가지고 있는 각 관점들을 논의하며 그 차이점을 이해하고 공유할 수 있다는 점에서 기존에 장시간 단절되어서 수행했던 요구사항 > 프로세스모델링 > 설계를 진행하는 과정을 뛰어넘는 민첩성과 효율성을 보여준다.
또한 쉽고 간편한 도구를 사용하여 빠른 시간내 에 지식 공유를 통한 협업을 가속화함으로써 서로간의 학습 및 탐색을 촉진하게 해주는 워크샵이라고 할 수 있다.
이벤트 스토밍의 준비사항
- 공간 : 깨끗한 벽 을 가진 넓은 워크샵 공간 1
- 참가자 : 고객 , 도메인전문가, 설계자, 개발자, 테스트 등 모든 이해 관계자
- 준비물 : 벽에 붙힐 A1 하얀색 전지, 마커 펜, 다양한 색의 포스트 잇 , 줄을 그릴 수 있는 다양한 색깔의 끈 테이프, 스카치 테이프
- 마음가짐 : 적극적이고, 긍정적이며 열린 마음가짐 , 대화하고 토론하고 나 설 수 있는 용기
- 열린 분위기로 활동을 촉진하고 리딩 할 수 있는 퍼실리테이터 (facilitation) 2
워크샵 방식
- 넓은 공간 (벽이나 넓은 책상)에 여러 장의 하얀 전지를 이어 붙여 설계 공간을 마련한다.
- 쉽게 접근 가능한 별도 공간에 다양의 색의 포스트잇과 기타 준비물을 올려 놓는다.
- 모든 참가자가 마커펜을 하나씩 들고 설계 공간을 바라보게 한다.
- 의자는 치우는 것이 좋다. (몸이 편하면 적극적으로 참여하지 않게 된다.)
- 퍼실리테이터의 지시에 따라 아래와 순서대로 진행한다. 모든 활동은 타임박싱 (Timeboxing)으로 집중하여 몰입하도록 유도한다.
포스트-잇 유형별 의미
| 유형 | 색깔 | 설명 |
|---|---|---|
| 도메인이벤트 | 오렌지색 | 발생된 사건, 과거시제동사로 표현 |
| 커맨드 | 파란색 | 이벤트를 트리거하는 명령 |
| 외부 시스템 | 핑크색 | 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템, 장비 |
| 액터 | 노란색 작은 포스트잇 | 개인 또는 조직의 역할 |
| 어그리게잇 | 노란색 큰 포스트잇 | 상태가 변경되는 데이터 |
| 정책 | 라일락 색 | 이벤트 조건에 따라 진행되는 결정 When [이벤트]then [커맨드] |
| 핫스팟(Hot spot) | 보라 색 | 의문, 질문, 미결정 사항 |
표] 이벤트 스토밍 포스트 잇의 유형
워크샵은 다음 순서로 진행한다.
도메인이벤트 식별 (30분) > 커맨드 식별 (30분)> 외부 시스템 도출 (20분) > 엑터 식별 (30분)> 흐름 설명 (30분)> 어그리게잇 식별(30분) > 컨텍스트 경계 정의(30분) >정책 식별(30분)> 컨텍스트 매핑 (30분)
도메인이벤트 도출
우선 시간의 흐름에 따라 비지니스의 상태 변경을 의미하는 도메인 이벤트를 도출한다. 참여자들이 각각 마커펜을 들고 오렌지색 포스트잇에 이벤트 명을 작성하여 붙이면 되는데 이벤트 명은 과거명으로 작성한다. 이벤트간의 공간을 두되 이벤트가 연쇄적으로 발행하는 경우 바로 옆에 붙인다. 같은 시점에 비지니스 조건에 따라 대체적으로 발생될 수 있는 이벤트는 아래에 같은 라인선상으로 붙인다.
도메인 이벤트는 비지니스의 어떤 상태를 생성,변경,삭제하는 요소이다. 시스템의 화면을 연상하지 말고 비지니스가 흘러감에 따라 비지니스를 구성하는 요소들의 상태가 어떻게 변경되는지를 생각하도록 한다.
여러 사람이 참여 시 혼잡할 수 있으니 대략 파악한 문제영역별로 사람들을 배정하던지 아니면 시스템을 사용하는 역할(사용자, 관리자등)으로 나누어서 사람들을 배정하여 업무별로 논의가 가능한 수준인 적절한 인원이(3~4명) 참여하게 한다. 아래 예시는 간단한 쇼핑몰이다. 상품이 등록되고 카탈로그가 조회되고 주문되고 배송되는 과정을 이벤트로 파악하였다.
커맨드 도출
이벤트를 트리거하는(발생시키는) 커맨드를 도출한다. 커맨드는 동사 형태가 된다. 파란색 포스트잇에 작성하여 붙인다. 커맨드는 이벤트를 보면 쉽게 유추할 수 있다. 하나의 커맨드에 의해 여러개의 이벤트가 연속 발생될 수 있으며 커맨드 하나에 조건에 따라 다른 이벤트가 발생할 수 있음을 유의하자.
아래 그림을 보면 상품등록됨 이벤트를 트리거 하는 상품등록 배송준비됨 이벤트를 트리거하는 배송준비 커맨드가 도출 되었다.
외부시스템 도출
커맨드 & 이벤트 발생 시 호출되거나 관련되는 레거시 시스템이나 외부 시스템 또는 장비를 도출하여 핑크색 포스트잇에 작성하여 이벤트의 오른쪽 상단에 붙인다. 본 시스템의 구현 대상이 아니지만 시스템의 기능 구현을 위해 연계가 필요한 시스템들을 모두 도출한다.
아래 그림을 보면 주문됨 이벤트와 연계되는 이메일시스템, 결제시스템등이 식별되었고 배송됨 이벤트와 연계되는 택배시스템이 도출되었다.
엑터 도출
엑터는 사람이나 조직이 될 수 있는데 역할 관점으로 도출한다. 엑터는 추상적으로 식별하지 말고 비지니스를 수행하는 구체적인 역할로 고려하여 도출한다. 즉 그냥 모든 업무에서 보편적으로 사용되는 회원, 관리자로 뽑지 말고 특정 비지니스를 실제적으로 수행하는 역할자를 도출하려고 노력해야 한다. 액터가 구체화 될 수록 식별하지 못한 커맨드와 이벤트가 추가적으로 도출 될 수 있다. 아래 그림을 보면 액터가 해당 업무에 밀접한 관리자, 구매자, 주문자, 배송자등으로 구체화된 것을 볼 수 있다.
액터는 노란색 작은 포스트잇을 사용하여 커맨드의 왼쪽 아래에 붙인다.
엑터를 도출하면서 다음과 같이 문장을 만들어 식별한 커맨드와 이벤트를 검토해 보자.
- 관리자가 상품등록을 하여 상품이 등록됨이벤트가 발생된다.
- 주문자가 주문취소를 하여 주문취소됨 이벤트가 발생된다.
문장이 자연스럽지 않다면 자연스럽게 커맨드와 이벤트를 변경하거나 새로 도출해 보자.
핫스팟 도출
진행하면서 의문이 들거나 참여하는 사람들이 결정하기 힘든사항 타 부서나 외부에 문의가 필요한 사항이 파악될 수 있다. 이런 내용을 잊지 않고 기록하기 위해 보라색 포스트잇을 사용한다. 이벤트 위쪽에 눈에 잘 보이도록 기울여서 붙여놓고 가정,경고,질문 , 미 결정사항을 남긴다.
어그리게잇 도출
어그리게잇 3 은 커맨드와 이벤트가 영향을 주는 데이터 요소이다. 액터와 마찬가지로 구체적으로 도출하면 좋다. 이벤트가 상태변경하는 요소들을 도출한다. 명사형이고 노란색 포스트잇에 작성하여 커맨드와 이벤트 사이의 상단에 겹쳐서 붙인다. 아래 그림과 같이 여러 개가 도출될 경우 이미
도출한 어그리겟잇 상단에 포개서 붙인다. 어그리게잇을 구체적으로 식별할 수록 도메인의 경계를 식별하는 것이 유용해 진다. 아래 그림을 보면 상품,상품카탈로그, 장바구니,장바구니 아이템 등이 식별되었다.
컨텍스트 경계 그리기
마이크로서비스 후보가 되는 컨텍스트 경계를 그려본다. 그동안 도출된 요소들 어그리게잇,액터,커맨드,이벤트를 고려하여 경계를 식별한다. 경계는 마커로 표시할 수도 있고 끈테이프로 표시할 수도 있다.
어그리게잇을 보면 경계를 구분할 수 있는데 떨어져 있는 공간에서 홀로 같은 어그리게잇이 식별 됬다면 그 어그리게잇 많이 식별된 중심으로 홀로 떨어져 있던 포스티잇(어그리게잇 및 커맨드,이벤트)을 이동시킨다. 즉 기능을 제공할 책임들을 어그리게잇 중심으로 모듈화 해야 함을 의미한다. 컨텍스트 경계의 이름을 부여한다. 식별된 어그리게잇을 단어명을 기반으로 컨텍스트를 규정할 수 있다.
구체적으로 어그리게잇을 식별했다면 어그리게잇이 달라지는 지점에서 어떻게 경계를 나눠야 될지 고민이 될 것이다. 아래 그림을 보면 상품, 상품 카탈로그가 도출되었는데 상품, 상품카탈로그 사이에 경계를 둘 수도 있다. 그렇지만 아래에서는 상품과 상품카탈로그를 같이 묶어 상품 컨텍스트에 두었다.
상품과 상품카탈로그가 다른 맥락으로 동작된다고 생각하면 이런 경우는 분리할 수도 있다. 또 다른 케이스로 주문 컨텍스트에 주문,주문아이템이 식별되었지만 같은 커맨드,이벤트내에서 연관되기 때문에 분리하지 않았다.
어느 정도 경계가 그려진 상태에서 살펴보면 핑크색 외부 시트메이 반복으로 사용된 것을 확인할 수 있다. 이렇게 반복으로 사용되는 외부시스템등을 분리하여 보자. 핑크색으로 도출하였던 외부 시스템들을 띄어서 여분의 공간에 배치한다.
정책 도출하며 연관관계 생각하기
아래 그림을 보면 경계가 그려졌고 외부시스템들이 별도로 배치되었다. 현재까지 파악된 관계 만으로도 외부시스템과 각 컨텍스트 경계 간의 관계를 그릴 수 있다. 다음은 정책도출이다. 정책은 라일락색 포스트잇을 사용한다. 정책은 이벤트 뒤에 따라오는 반응 적인 비지니스 로직이며 어디인가에 존재하는 커맨드를 트리거 한다. 정책은 다음과 같이 정의된다.
[이벤트] 할 때는 항상 [커맨드] 한다
따라서 정책은 이벤트와 커맨드 사이에 존재한다. 이런 정책이 호출하는 커맨드는 같은 컨텍스트 경계 내에 존재할 수도 있고 다른 컨텍스트 경계의 커맨드를 호출할 수 도 있다. 따라서 정책을 도출함으로써 다른 컨텍스트 경계와의 관계를 식별할 수 있다.
아래 그림을 보면 반송되면 상품 재고가 변경되어야 한다는 정책을 도출했다. 이는 배송 컨텍스트 경계에서 반송됨 이벤트에 따라 상품 컨텍스트 경계의 상품재고변경 커맨드가 트리거 됨을 의미 한다. 또한 주문 컨텍스트 경계에서 주문됨 이벤트가 발생 시 배송 생성이라는 정책을 도출함으로써 배송 컨텍스트 경계의 배송 준비 커맨드가 트리거 됨을 알 수 있다.
라일락 색의 정책을 가리키는 방향을 파란색 끈 테이프를 통해 표현해 준다. 방향을 화살표로 표현해 준다.정책은 수행되어야 할 컨텍스트 경계에 붙여 준다.
컨텍스트 매핑하기
이렇게 하면 대략의 컨텍스트 경계가 식별되었고 각 컨텍스트 경계 간의 관계가 파악되었다. 이러한 관계를 컨텍스트 맵으로 표현해 보자. 각 호출 관계의 방향 및 호출 할 때 동기 방식의 호출이 필요한지 비동기 호출 방식이 필요한지 판단하여 작성해야 된다. 비지니스 일관성의 실시간성을 만족해야 할 관계는 동기 호출로 표현하고 결과적 일관성으로 충분한 관계는 비 동기식 호출로 표현한다.
일반적으로 동기 관계는 실시간 동시 처리를 위해 의존도를 높이고 비동기 관계는 의존성을 낮춘다. 따라서 반드시 실시간 정합성이 필요하지 않다면 비동기 호출을 고려해야 한다 . 비동기 호출로 결합도를 낮춘다면 각 서비스의 확장 및 독립성, 탄력성이 강화될 것이다.
컨텍스트 맵은 별도 기 작성한 이벤트 스토밍 결과를 간략하게 옮겨 별도 작성하는데 식별된 컨텍스트 경계명을 포스트 잇에 적어 붙이고 관계를 표현해 주면 된다. 동기 호출은 실선으로 비동기 호출은 점선으로 표현해 주면 된다. 수정이 편한 색깔이 다른 끈 테이프를 사용할 수도 있다.
아래 그림에서 보면 주문 시 결제시스템과 연동되는 경우와 배송 처리시 배송시스템과 연동되는 경우를 제외하고는 모든 연관관계가 비동기로 정의되었다. 이런 경우 이메일시스템과 배송시스템의 장애의 경우에도 주문을 계속 받을 수 있는 독립성과 확장성을 제공한다.
이렇게 도출된 컨텍스트가 마이크로서비스 후보가 된다. 최종적으로 마이크로서비스가 되려면 추가적으로 다음과 같은 질문을 고려해서 판단할 수 있다.
- (운영 조직 측면) 하나의 팀이 독립적으로 운영 가능한 단위인가?
- (배포 측면) 독립적으로 배포 가능한 단위인가?
- (변경 영향도) 변경 시 영향 받는 마이크로서비스가 존재하는가? 이러한 점을 모두 고려했다면 최종 마이크로서비스로 식별한다.
이벤트 스토밍 결과를 프로젝트가 진행되는 공간에 그대로 붙여 놓아서 계속 보완하고 리뷰 될 수 있게 하는 것이 제일 좋고 최종적인 문서나 협업시스템 에 기록하여 팀원들이 항상 참고하게 할 수 도 있다.
마이크로서비스 상세설계를 위한 입력물
이벤트 스토밍 결과는 서비스 상세설계를 위한 출발점이 된다. 아래 그림과 같이 식별된 컨텍스트 경계 별로 식별된 커맨드, 도메인 이벤트, 어그리게잇 , 외부시스템, 리스크등을 정리할 수 있다. 상세설계를 이를 더 상세히 하는 활동이 된다. 아래 그림과 같이 활용할 수 있다.
