이벤트 스토밍이란 도메인에 관련된 모든 이해 관계자가 모여서 화이트 보드와 포스트잇을 활용하여 이벤트를 중심으로 업무들 간의 상호 연관성을 찾기 위해 진행하는 워크숍 방법론이다.
도메인 전문가와 개발자를 학습 과정에 참여시키기 위해 설계되었고, 모든 사람들이 시각적으로 도메인에 시각적으로 접근할 수 있게 해준다.
이벤트 스토밍의 가장 큰 목적은 도메인지식을 공유함으로써 전체 비스니스가 어떻게 돌아가는지 한눈에 볼 수 있는 지도(타임라인)를 만드는 것이다. 각 도메인 전문가들의 도메인 지식은 모두 분산되어 있기 때문에 한번에 전체 지도를 그리기 힘든데, 이벤트 스토밍은 그 지식을 모아 정리할 수 있도록 한다.
이벤트 스토밍을 하기 위한 준비물은 “포스트잇과 펜”이다.
어떤 이벤트와 정책, 애그리거트가 있을지 생각한 뒤, 순서에 따라 각 용도에 맞는 포스트잇으로 적어 붙이면 된다. 아래는 색깔별 포스트잇의 용도이다.
📌 포스트잇의 용도
| 이름 | 설명 |
|---|---|
| 도메인 이벤트 Domain Event | 비즈니스 프로세스에서 발생하는 이벤트이다. 과거형으로 작성한다. |
| 액터 Actor |
- 뷰를 통해 명령을 실행하는 사람을 뜻한다.
명령 Command
- 사용자가 실행하는 명령이다.
정책 Policy
- 이벤트가 발생했을 때의 시스템의 반응을 규약한 것이다.
외부 시스템 External System
- Third Party 시스템을 뜻한다. (ex. 결제 시스템, 배송회사)
뷰 Veiw
- 사용자가 시스템에서 작업을 수행하기 위해 상호 작용하는 뷰를 의미한다.
애그리거트 Aggregate
- 단일 단위로 취급할 수 있는 도메인 개체의 모음이다.
이벤트 스토밍의 순서는 세 단계로 나뉜다.
1. Big Picture
전체적인 그림을 그리는 첫번째 단계이다. 이 때는 이벤트와 핫스팟, 외부 시스템, 액터를 적는다.
도메인 객체의 상태를 변화시키는 이벤트를 전부 적어주고 각 컨텍스트에서 어떤 이벤트들이 생성되고 전달되는지 파악한다.
이 단계가 끝나고 나면 이벤트의 타임라인을 통해 바운디드 컨텍스트를 대략적으로 찾을 수 있다.
2. Process Modelling
Big Picture 단계에서 더 나아가 정책, 명령을 뽑아낸다. 이 과정에서 기존에 적어놨던 이벤트나 외부 시스템, 액터를 수정할 수도 있고 이벤트를 추가로 뽑아내는 것도 가능하다.
정책은 프로세스 매니저라고 부를 수도 있는데, 이벤트를 받았을때 처리되는 조건 혹은 이벤트가 생성되는 조건을 뜻한다.
프로세스 모델링이 끝나면 이벤트의 처리주체 및 정책, 이벤트를 발생시키는 커맨드와 커맨드 주체(Person, System 등) 등의 세부적인 사항들이 드러난다.
3. Software Design
마지막 단계인 Software Design은 개발자들이 주도적으로 참여하는 단계이다.
이제 프로그래밍 즉, 설계를 하기 위해 애그리거트를 뽑아낸다.
소프트웨어 디자인이 끝나면 실제로 소프트웨어를 개발할 수 있다. 변경해야하는 객체들, 변경 조건 및 방법 등이 다 명확해졌기 때문이다.
이벤트 스토밍을 할 때에는, 이벤트를 배치하는 순서에도 신경써야한다. 이벤트 사이의 순차적 관계가 있는 경우에는 좌 →우으로 배치, 동시에 발생하는 이벤트일 경우 상 →하로 배치하여 사용 타임라인이 잘 드러나도록 해야한다.
실제 적용에는 위의 내용을 기반으로 각 내용을 변경해서 쓰는 경우가 많다. 이벤트 스토밍은 상황과 환경에 따라 적절한 방식으로 응용해서 진행하는 것이 좋다.
다만, 그것을 변경하는 이유와 효과를 확실히 인지하고 사용해야한다.