이벤트스토밍은 비즈니스 프로세스를 모델링하기 위한 워크숍이다.
이벤트스토밍은 사람들이 모여 비즈니스 프로세스에 관해 브레인스토밍하고 신속하게 모델링하기 위한 로우테크(low-tech) 활동이다.
이벤트스토밍의 참가자는 비즈니스 프로세스에 대해 다룬다.
포스트잇을 활용하여 도메인 이벤트를 시간의 흐름에 따라 표현하고, 모델의 모든 구성요소가 비즈니스 프로세스의 작동 방식을 설명할 때까지 단계별로 개념을 모델에 추가하면서 개선한다.
이벤트스토밍에는 해결하고자 하는 비즈니스 도메인에 관련된 엔지니어, 도메인 전문가, 제품 소유자, UI/UX 디자이너 등 다양한 그룹의 사람이 참가하는 것이 좋다.
다만 참가자의 규모가 10명 이상이 되면 모든 참가자가 과정에 기여하는 것이 어려워진다.
이벤트스토밍은 펜과 종이만 사용하기 때문에 로우테크 워크숍으로 간주된다.
세션을 진행하면서 아래와 같은 준비물이 필요하다.
- 모델링 공간(큰 벽)
- 포스트잇
- 마커
- 간식(긴 시간 진행됨)
- 회의실(의자가 없고 넓음)
이벤트 스토밍은 탐색하려는 비즈니스 도메인에 관련된 **도메인 이벤트(domain event)**를 브레인스토밍하는 것으로 시작한다.
도메인 이벤트는 이미 발생한 일을 설명하기 때문에 과거형으로 작성한다.
초기 단계에는 이벤트의 순서나 중복에 대해 걱정하지 않고 새로운 이벤트를 추가하는 속도가 느려질 때까지 비즈니스 도메인에서 발생할 수 있는 것을 브레인스토밍한다.
생성된 도메인 이벤트를 비즈니스 도메인에서 발생하는 순서대로 정리한다.
성공 시나리오부터 시작하여 에러가 발생하는 경로나 다른 비즈니스 의사결정을 내리는 시나리오를 추가한다.
시나리오의 흐름은 화살표를 사용해 표현할 수 있다.
또한 잘못된 이벤트를 수정하고 중복을 제거하며, 빠뜨린 이벤트도 추가한다.
전체 구성을 보고 프로세스에서 주목할 만한 포인트를 식별한다.
병목구간, 자동화가 필요한 단계, 도메인 지식이 없는 경우처럼 이런 포인트로 쉽게 돌아오거나 나중에 다시 다룰 수 있도록 명확하게 표시하는 것이 중요하다.
해당 단계에서만 고충점을 추적하는 것이 아니라 전 과정에서 이슈나 관심사가 나오면 고충점으로 기록한다.
컨텍스트나 관심사가 바뀌는 것을 나타내는 **중요 이벤트(pivotal event)**를 찾는다.
이벤트 타임라인 과정에서 발생하는 중요한 상황 변화를 나타내어 이벤트 전후로 세로로 선을 긋는다.
커맨드는 무엇이 이벤트 또는 이벤트의 흐름을 시작하게 하는지를 설명한다.
커맨드는 시스템의 오퍼레이션을 설명하고 도메인 이벤트와는 반대로 다음과 같이 명령형으로 작성한다.
- 캠페인을 게시한다.
- 트랜잭션을 롤백한다.
- 주문을 제출한다.
커맨드가 생성하는 이벤트 앞에 포스트잇을 붙이며 비즈니스 도메인 내의 사용자 페르소나(액터)를 커맨드와 함께 붙인다.
모든 커맨드가 액터와 연관되는 것은 아니기 때문에 분명한 곳에만 추가한다.
**자동화 정책(automation policy)**은 이벤트가 커맨드의 실행을 시작하는 시나리오다.
다시 말해, 커맨드는 특정 도메인 이벤트가 발생할 때 자동으로 실행된다.
어떤 의사결정 조건이 만족할 때만 문제의 커맨드를 시작해야 한다면 그 의사결정 조건을 정책 포스트잇에 명시하는 것처럼 이벤트와 커맨드를 연결하는 역할을 한다.
- 예를 들어, '불만이 접수됐다' 이벤트 이후에 '상부에 보고한다' 커맨드를 시작해야 하지만 VIP 고객으로부터 접수된 불만인 경우에 한정된다면 'VIP 고객에 한함'이라는 조건을 정책 포스트잇에 명시한다.
읽기 모델은 도메인에서 액터가 커맨드를 실행하는 의사결정을 내릴 때 사용하는 시각적 데이터다.
읽기 모델은 액터의 의사결정을 돕는데 필요한 정보의 원천에 대해 짧게 설명하며 스크린, 리포트, 알림 등이 될 수 있다.
액터가 읽기 모델을 본 후 커맨드를 실행하기 때문에 커맨드 앞에 둔다.
이 단계에서는 외부 시스템 연동 정보를 보강한다.
외부 시스템은 탐색 중인 도메인에 포함되지 않는 모든 시스템으로 커맨드를 실행(입력)할 수도, 외부 시스템으로 전달(출력)할 수도 있다.
예를 들어,
- 외부 시스템이 '주문을 배송한다' 커맨드를 실행한다. (입력)
- 배송이 승인되면(이벤트) 정책을 통해 외부 시스템과 통신한다. (출력)
이 단계가 끝나면 모든 커맨드는 액터 또는 정책에 의해 실행되거나 외부 시스템이 호출하여 실행된다.
모든 이벤트와 커맨드가 표현되면 애그리거트의 개념을 포함하여 모델을 구성한다.
애그리거트는 커맨드를 받고 이벤트를 생성하는 역할을 한다.
마지막 단계에서는 서로 연관된 애그리거트를 찾는다.
애그리거트는 기능이 밀접하게 연결되거나 정책을 통해 연관될 수 있는데, 애그리거트의 그룹은 바운디드 컨텍스트 경계의 후보가 된다.
비즈니스 도메인의 큰 그림을 탐색한 후, 개별 비즈니스 프로세스에 대한 이벤트스토밍을 진행한다.
이벤트스토밍 진행 과정은 규칙이 아니라 가이드이다.
이벤트스토밍을 처음 도입하는 경우, 1단계부터 4단계를 진행해서 비즈니스 도메인의 큰 그림을 탐색하는 것이 좋다.
그렇게 되면 비즈니스 도메인을 폭넓게 다루게 되고, 유비쿼터스 언어를 구축하는 토대가 만들어지기도 하고, 바운디드 컨텍스트 경계의 윤곽을 그릴 수 있다.
큰 그림을 탐색하였다면 개별 비즈니스 프로세스를 전담으로 다루는 이벤트스토밍 세션을 진행한다.
이벤트스토밍을 통해 도메인 이벤트, 커맨드, 애그리거트 등 모델을 얻게 되지만, 이보다 중요한 것은 다음과 같다.
"다양한 이해 관계자 간의 지식 공유"
"비즈니스와 멘탈 모델의 일치"
"충돌하는 모델의 발견"
"유비쿼터스 언어 구축"
도출된 모델은 이벤트 소싱 도메인 모델을 구현하는 기반이 되기도 한다.
다음과 같은 경우에 이벤트스토밍이 필요하다.
유비쿼터스 언어 구축하기
비즈니스 프로세스 모델을 구축할 때 용어를 통일하고 동일한 언어를 사용한다.
비즈니스 프로세스 모델링하기
이벤트스토밍은 비즈니스 프로세스 모델을 구축하는 데 효과적이다. DDD를 지향하는 구성요소에 기반하기 때문에 애그리거트와 바운디드 컨텍스트의 경계를 발견하는 데 효과적이다.
새로운 비즈니스 요구사항 탐색하기
새로운 기능에 대해 생각을 공유하거나 비즈니스 요구사항에서 다루지 않는 것을 발견한다.
도메인 지식 복구하기
현대화가 필요한 레거시 시스템에서 모든 참가자의 지식을 하나의 응집된 그림으로 만든다.
존재하는 비즈니스 프로세스의 개선 방법 탐색하기
비즈니스 프로세스를 end to end 관점에서 바라보며 효과적이지 못한 부분을 발견하고 개선한다.
새로운 팀원의 훈련
도메인 지식을 확장하는 기회이다.
- 그룹이 대상이라면 진행 개요를 빠르게 소개한다.
- 개인적으로 진행한다면 하려는 것, 탐구할 비즈니스 프로세스, 워크숍에서 사용할 모델링 요소 등을 설명한다.
- 참가자들이 각각의 모델링 요소들을 기억하기 쉽게 서로 색이 다른 포스트잇을 이용한다.
- 범례는 워크숍이 진행되는 동안 모든 참가자가 볼 수 있어야 한다.
이벤트스토밍은 그룹 활동이며, 모두가 참여할 수 있어야 한다.
그룹 활동의 활발함이 떨어지면 질문을 던져서 과정을 북돋거나 워크숍의 다음 단계로 넘어간다.
모든 참가자가 모델링 활동과 논의에 참여할 수 있도록 질문을 던져서 유도한다.
이벤트스토밍은 집중적이기 때문에 휴식을 중간 중간 가진다.
다시 시작할 때 현재까지 진행된 모델링을 리뷰해서 모든 참가자가 협력적인 모델링 분위기로 돌아오게 돕는다.
온라인으로 이벤트스토밍을 할 때는 커뮤니케이션이 힘들어져 좀 더 참을성을 가져야 한다.
원격 이벤트스토밍은 참가자의 수가 적을 때 효과적이기 때문에 5명을 넘지 않는다.
이벤트스토밍은 협업을 통해 비즈니스 프로세스를 모델링하는 워크숍이다.
도출되는 모델 이외에 지식 공유라는 중요한 과정을 얻을 수 있다.
이벤트스토밍은 자전거를 타는 것과 같이 이론을 공부하기 보다 직접 경험하며 배우면 된다.
이벤트스토밍 활동은 DDD를 적용하려는 사람에게도, 그 밖에 비즈니스 프로세스에 대한 이해도를 올리고자 하는 사람에게 많은 도움이 된다.
프로젝트를 시작하기 전, 프로젝트를 진행하는 도중, 프로젝트를 유지보수하는 과정 언제든 상관없다.
모든 의사결정은 더 나은 비즈니스 프로세스를 위해 이루어지기 때문에 이벤트스토밍을 통해 서로 간의 지식을 공유하며 더 나은 비즈니스 프로세스를 발견하면 좋겠다.