TIL - 이벤트 스토밍 해보기

2차 프로젝트 돌아보기

이번 2차 프로젝트의 설계과정 중 우리 팀은 주문을 어떤 식으로 처리할지 회의했었다.

• API를 실행하는 사용자는 누구인 지
• 특정 이벤트 수신/발행하는 서버는 어디인 지
• 무엇을 담아서 이벤트를 발행할지
• 특정 비즈니스의 처리 순서는 어떻게 되는지

하지만 이런 회의에도 불구하고 프로젝트 후반부까지 이벤트 명세에 대해 수정했어야 했다.

프로젝트가 종료되고 나는 "우리 팀이 왜 이렇게 많은 수정과 회의를 반복해야 했었는지"에 대해 생각해 보았고
그 이유를 "프로젝트를 설계할 때, 이벤트 스토밍을 진행하지 않아서"라고 생각했다.

우리팀 설계의 문제점

우리 팀은 단순히 구두로써, 이벤트 처리에 대해 회의하고 명세를 작성했다.

그렇다 보니 개발 과정 중 회의의 내용이 기억이 안 나거나
회의록으로 기록해 놔도 찾아보기 번거롭다는 단점이 있었다.

이벤트 시퀀스 다이어그램을 만들어봄으로써 해결할 수도 있지만
이벤트 스토밍이 더 명확한 방법이 될 거라 생각했다.

그래서 이번에 나 혼자 따로 종료된 프로젝트에 대해 이벤트 스토밍을 해보았다.

이벤트 스토밍이란?

이벤트 스토밍에서, 각 색깔의 역할

"이벤트 스토밍(Event Storming)은 DDD의 원칙을 실질적으로 적용할 수 있는 실천법으로, DDD의 핵심 개념 중 하나인 도메인 이벤트(Domain Event)를 중심으로 도메인을 시각화하고, 이를 통해 복잡한 시스템을 설계하는 방법입니다.

이 기법은 모든 이해관계자(개발자, 도메인 전문가, 비즈니스 리더 등)가 협력하여 도메인의 상태 변화를 도출하고, 이를 기반으로 마이크로서비스를 설계할 수 있는 혁신적인 표준 방법론입니다."
(글 및 이미지 출처 : https://www.msaschool.io/operation/design/design-three/)

쉽게 말해서, 이벤트 스토밍은 이벤트를 색깔을 가진 포스트잇으로 나타내 시각화한 것을 말합니다.

이미 끝난 프로젝트로 이벤트 스토밍 해보기

draw.io에서 진행해본 이벤트 스토밍

이전 2차 프로젝트의 주제인 물류 대행 회사 프로젝트의 이벤트 스토밍 결과입니다.
주문이 어떤 순서로 처리될지를 중점으로 만들어봤습니다.

기존 프로젝트에는 재고 차감 같은 것이 없었는데 내가 추가해 보았다.
그리고 나중에 결제 시스템도 추가해 보면 좋을 것 같다.

또한 슬랙 메시지 발행 같은 기능을 설계는 했었지만 이번 기간에서 구현하지 못했어서
그 부분은 제외하고 이벤트 스토밍을 진행했다.
( ps. 이후에 외부 시스템을 나타내는 분홍색 포스트잇에 슬랙 시스템과 결제 시스템이 기록될 예정이다. )

이벤트 스토밍을 하면 아래와 같은 헷갈릴만한 구현 요구사항들을 나타내어 나중에 찾아보기 편합니다.

• 이벤트를 발행/수신하는 주체(사용자)
• 서버(애그리거트) 별 구현해야 하는 이벤트 목록
• 특정 비즈니스(이벤트)의 처리 순서
• 이벤트 트리거
• 외부 시스템

그 외에 사용자 입장에서 보는 화면을 의미하는 읽기 모델(주로 연두색으로 표현)등이 있다.

 

- 적용 예시 (음식 배달 앱)

이미지 출처 :  https://www.msaschool.io/operation/design/design-three/

마무리

다음 프로젝트 때는 프로젝트 설계 과정에서 이벤트 스토밍을 진행해 보면 좋을 것 같다.
그리고 취소나 수정 같은 로직들도 그려보면 더욱 깊이 있는 설계가 될 것 같다.

 

그리고 이벤트 스토밍을 보고 다시 한번 도식화의 중요성을 깨달았다.

문서화를 통해 글로써 나타내는 것도 좋지만,
회의 내용을 빠르게 공유하고 적용하는 데에는 역시 그림만 한 게 없는 것 같다.