들어가며
필자가 이벤트 스토밍을 진행할 때 헷갈리는 부분은 2가지였다. 첫 번째는 다양한 포스트잇 색상의 의미였고, 두 번째는 활동의 진행 순서였다. 이번 글에서는 이 두 가지에 대한 요약을 먼저 하고, 필자가 이벤트 스토밍을 진행하며 참고한 자료 및 예시들을 공유하려 한다.
필자는 처음 진행할 때 많이 헷갈렸지만 아래 두 내용을 참고하여 4~5개의 주제로 진행해보니 익숙해졌다.
만약 애그리거트가 무엇인지 생소하다면 아래의 글을 먼저 읽는 것이 도움이 될 것이다.
2022.02.06 - [MSA 설계 & 도메인주도 설계] - [DDD] 애그리거트란?
이벤트 스토밍(Event storming)이란?
마이크로서비스 간의 의존성을 줄이기 위해서 도메인 이벤트를 활용하는 것이 중요하다. 도메인 이벤트는 비동기 메시지 기반이기 때문이다. 하지만 이러한 도메인 이벤트를 통한 서비스 간 의존관계를 식별하는 방법이 쉽지 않다. 그래서 이탈리아 출신 DDD 컨설턴트 알베르토 브란돌리니가 설계 기법을 고안해 냈는데, 이것이 이벤트 스토밍이다.
특징
모든 이해관계자가 화이트보드 앞에 모여 서로가 가지고 있는 관점을 논의한다. 여기서 모든 이해 관계자란 고객, 도메인 전문가, 설계자, 개발자, 테스터 등 프로젝트와 관련이 있는 사람들이다. 그렇기 때문에 이벤트 스토밍은 참여자들의 도메인 지식 및 개발 등 여러 가지 관점의 차이를 이해하고 공유할 수 있는 활동이다. 이는 아래의 단계를 진행하며 단절되었던 문제점들을 뛰어넘어 민첩성과 효율성을 보여준다.
- 요구사항 분석
- 프로세스 모델링
- 설계
TIP & 주의사항
- 의자를 치워서 활동에 적극적으로 참여하도록 유도한다.
- 참여자들은 적극적이고 긍정적이며, 열린 마음 마음가짐과 토론 및 대화를 주저하지 않는 용기를 갖는다.
- 다른 참여자의 의견을 무시하거나 반박하기보다 토론을 통해 의견을 맞춰간다.
- 마커 펜은 모든 참여자가 하나씩 가질 수 있도록 충분히 준비한다.
- 넓은 공간을 확보한다.
- 모든 참여자들이 마커펜을 하나씩 들고 설계 공간을 바라보게 한다.
- 퍼실리테이터의 지시에 따라 워크숍을 진행한다.
- 모든 활동은 제한된 시간에 진행하여 집중력을 유도한다.
- 참여하고 있는 모든 사람들이 이해할 수 있는 유비쿼터스 언어(단어)를 사용한다.
포스트잇 색상의 의미
도메인 이벤트, 커맨드, 외부 시스템, 액터, 애그리거트, 정책을 의미하는 6개의 포스트잇이 메인이다. 이 외에도 핫스팟(Hot spot)이라는 보라색 포스트잇이 하나 더 있다. 핫스팟은 질문 또는 미결정 사항을 적어 비스듬하게 붙여놓고 해결될 경우 탈착 한다.
진행 순서
1단계: 도메인 이벤트 도출 (30분)
시간의 흐름에 따라 비즈니스 상태 변경을 의미하는 도메인 이벤트를 도출한다. 도메인 이벤트는 비즈니스의 어떤 상태를 생성, 변경, 삭제하는 요소다. 도메인 이벤트는 과거 동사 형태로 표현한다.
예: 상품 등록됨, 장바구니 변경됨
필자는 처음에 이벤트 스토밍을 진행할 때 시스템의 기능 관점으로 모든 CRUD를 나타내려고 했다. 그러다 보니 비즈니스에 대한 핵심적인 흐름을 파악하기도 힘들었다. 그리고 마스터 데이터를 단순히 조회하는 이벤트까지 표현하니 포스트잇이 너무 많아졌다. 상태의 변화에 초점을 맞추게 되면 Command 만을 도출하기 쉽고, 상태를 변경하기 위한 Query 들만 “조회됨”으로 표현할 수 있다.
2단계: 커맨드 도출(30분)
이벤트를 발생시키는 커맨드를 도출한다. 커맨드는 동사 형태로 표현한다.
예: 상품 등록, 장바구니 변경
3단계: 외부 시스템 도출(20분)
커맨드 & 이벤트 발생 시 호출되거나 관련되는 레거시 시스템이나 외부 시스템 또는 제어되는 장비를 도출한다. 연계가 필요한 것을 표현한다. 명사 형태로 표현한다.
예: 택배 발송 시스템, SMS 전송 시스템
4단계: 엑터 도출(30분)
액터는 사람이나 조직이 될 수 있다. 역할을 관점으로 도출하는데, 비즈니스를 수행하는 구체적인 역할로 도출한다. 명사 형태로 표현한다.
예: 관리자, 구매자, 주문자, 배송자
5단계: 애그리거트 도출(30분)
애그리거트는 이벤트가 상태를 변경하는 요소의 묶음이다. 여러 개가 도출될 경우에는 이미 도출한 애그리거트 상단에 겹쳐서 붙인다. 애그리거트를 구체적으로 식별할수록 도메인의 경계를 식별하는 것이 유용해진다. 명사 형태로 표현한다.
예: 상품, 장바구니, 주문
6단계: 컨텍스트 경계 정의(30분)
컨텍스트 경계는 마이크로서비스의 서비스의 단위 후보가 된다. 1~5단계를 통해 도출된 요소들을 고려하여 경계를 식별한다. 서비스의 부하적인 관점이나, 애그리거트의 포함관계, 관리하는 조직의 구성 등에 따라 구분한다. 또한 구현 시 참조나 통신이 많이 발생할 것으로 예상되는 애그리거트로도 묶을 수도 있다.
컨텍스트 경계를 정하는 방법은 다양하기 때문에 몇 가지 사례를 참고하는 것이 좋을 것으로 생각된다. 아래는 필자가 경계를 나눌 때 참고했던 예시들이다.
7단계: 정책 도출(30분)
컨텍스트 경계가 그려지면 각 경계 간의 비즈니스적 연관관계에 따라 정책을 도출한다.
[이벤트]할 때는 항상 [커맨드]한다.
를 만족하는 비즈니스 관계를 찾고, 이벤트 포스트잇 우측 하단에 정책 포스트잇을 정의하여 붙인다.
8단계: 컨텍스트 매핑(30분)
호출 관계를 명확히 이해할 수 있도록 컨텍스트 다이어그램을 그린다. 이벤트 스토밍을 통해 도출된 애그리거트들과, 외부 시스템들, 프론트엔드를 이용하여 호출관계를 시각화한다.
아래는 필자가 이벤트 스토밍 진행 후 도출한 컨텍스트 다이어그램이다.
사용자 서비스의 경우 우리가 필요한 대부분의 기능을 제공하고, 잘 만들어진 오픈소스들이 많기 때문에 향후 교체될 예정이다.
마치며
이번 글에서는 이벤트 스토밍에서 사용되는 포스트잇의 의미와 진행 순서에 대해 살펴보았다. 처음 MSA를 도입하고자 할 때 애매모호한 부분이 "서비스를 어떻게 나눌 것인가?"에 대한 고민인데, 이벤트 스토밍을 진행해보니 어느 정도 원하는 결과를 도출해 낼 수 있었다. 필자의 경우에는 조직에서 처음 이벤트 스토밍을 진행해서 외부 레슨을 통해 서비스를 검증하는 과정을 가졌다. 유엔진솔루션즈 장진영님의 원포인트 레슨에서 "반드시 살아있어야 하는 서비스와 상대적으로 죽어도 되는 서비스를 분리해 내는 것"의 관점에서 서비스를 나누는 것이 인상 깊었다. 예를 들어 위의 컨텍스트 다이어그램 예시에서 수집 서비스가 도출되었는데, 여기서 수집하는 로직과 수집된 데이터를 조회하는 로직을 분리하여 수집서비스를 라이트 하게 가져가는 것이다.
필자는 화이트보드 대신 Miro 플랫폼을 이용하여 이벤트 스토밍을 진행했다. 소규모 혹은 원격지에서 이벤트 스토밍을 진행할 때 유용했다. 아래는 Miro 플랫폼에서 이벤트 스토밍을 진행한 것이다.
참고자료
[1] 마이크로서비스 모델링 - 이벤트 스토밍 | 2020 | SK C&C 기술블로그 | 링크
[2] 도메인 주도 설계 철저 입문 | 2022 | 나루세 마사노부 | 링크
[3] 도메인주도 설계로 시작하는 마이크로서비스 개발 | 2021 | 한정헌, 유해식, 최은정, 이주영 | 링크
[4] 이벤트 스토밍 | MSA School | 링크
'MSA 설계 & 도메인주도 설계' 카테고리의 다른 글
Microservice Architecture의 서비스 설계, 개발, 관리 방식 (8) | 2023.04.01 |
---|---|
[MSA] 헥사고날 아키텍처(Hexagonal Architecture) (2) | 2022.02.21 |
[DDD] 도메인 계층의 Structure (0) | 2022.02.08 |
[DDD] 인터페이스 계층과 응용 계층의 구현 (0) | 2022.02.07 |
[DDD] 애그리거트란? (0) | 2022.02.06 |