이번에 도메인 주도 개발 시작하기 라는 책으로 스터디를 진행중이다. 그리고 이 책에서 배운 내용을 토대로 업무 코드에 DDD를 적용해보고자 했다. 그 과정에서 event storming을 이용해서 전체 비즈니스 로직이 어떻게 돌아가고 있는지 해당 도메인에 대한 이해도를 높이고자 했다.
event storming이란?
도메인에 관련된 모든 이해 관련자가 모여서 화이트 보드와 포스트잇을 활용하여 이벤트를 중심으로 업무들 간의 상호 연관성을 찾기 위해 진행하는 워크숍 방법론.
도메인 전문가와 개발자를 학습 과정에 참여시키기 위해 설계되었고 코드를 생각하지 않고 모든 사람들이 시각적으로 도메인에 대해 시각적으로 접근할 수 있게 해준다.
event storming을 하는 이유?
가장 큰 목적은 도메인 지식을 공유함으로써 전체 비즈니스가 어떻게 돌아가는지 한눈에 볼 수 있는 지도를 만드는 것이다. 각 도메인 전문가들의 도메인 지식은 모두 분산되어 있기 때문에 한번에 전체 지도를 그릴 수 없고 bottom-up 방식으로 전체 지도를 만들 수 있게 하는 방법론이 event storming이다.
하지만 사실 내가 이번에 event storming을 하게 된 이유는 도메인 지식 학습보다는 기존 코드에 DDD를 도입하기 위한 설계 작업의 의미가 더 컸다. (애초에 event storming을 진행하는 사람들이 모두 개발자이기도 했다.) 해당 과정에서 도메인 모델로 볼 수 있는 entity 및 value object를 뽑아내고 해당 도메인 모델이 사용자 및 외부 시스템과 어떻게 상호 작용하는지 분석하고 이를 토대로 아키텍처를 설계하고자 했다.
event storming을 하는 방법
event storming을 하는 거엔 위에서 말했듯이 준비물은 간단하다. 화이트 보드, 포스트잇, 펜.
포스트잇마다 및 펜 마다 각각의 의미가 있다!
- domain event : 주황색
- command : 파란색
- external system : 핑크색
- actor : 노랑색 (사람 모양)
- query model / information : 초록색
- hotstpot : 빨간색 (회의하다가 이야기 하고 싶은 주제 표시)
- aggregate : 펜으로 묶어서 표시 또는 노랑색
포스트잇은 처음부터 생각나는 것부터 붙이는 게 아니다. 위의 그림처럼 이벤트 스토밍 과정에도 순서가 존재한다. 이 때 모든 순서를 관통하는 것은? 이벤트는 모든 과정에서 추출할 수 있다!
-
Big Picture
전체적인 그림을 그리는 첫번째 단계. 이 때는 이벤트를 포함해서 핫 스팟, 외부 시스템, 액터를 뽑아낸다. -
Process Modelling
Big Picture 단계에서 더 나아가 정책, 명령, 정보를 뽑아낸다. 이 과정에서 기존의 뽑아냈던 이벤트나 외부 시스템, 액터를 수정할 수도 있고 당연히 이벤트를 추가로 뽑아내는 것도 가능하다. -
Software Design
마지막 단계인 Software Design은 개발자들이 주도적으로 참여하는 단계이다. 이제 프로그래밍 즉, 설계를 하기 위해 aggregate를 뽑아낸다.
이벤트 스토밍 과정에서 뽑아낸 이벤트, 명령, 외부 시스템 등등의 관계를 나타낸 그림이다. actor는 command를 내리고 command의 결과로 external system 또는 aggregate로 불러지고 이 둘에 의해 event가 발생한다. event의 결과로는 information 또는 policy 가 발생한다. 복잡하게 썼지만 결국 위의 그림을 말로 풀어쓴 것 뿐이다.
이 순서는 멋대로 바꿔서는 안된다!
event storming 해 본 후기
현재 우리팀은 기존 프로젝트를 분리하는 방향으로 가고 있는데 이 방향에서 다들 DDD를 적용하기 위해 공부하고 회의하는 과정을 반복하고 있다. event storming도 이런 과정에서 한 팀원의 제안으로 진행해보게 되었다.
이번에 event storming을 진행하면서 사실은 굉장히 시행착오가 많았다. 위에서 말했던 추출했던 이벤트, 명령, 외부 시스템 등등을 뽑아내고 이 관계를 정의하면서 순서가 뒤바뀌기도 했고 3개의 단계에 나누어서 진행을 하지 않고 처음에는 무조건 이벤트를 뽑아내고 이벤트를 발생시키는 원인을 뽑아내는 방식으로 진행하기도 했다. 이렇게 진행하다보니 점점 체계가 없는 느낌을 느꼈고 (귀에 붙이면 귀걸이 코에 붙이면 코걸이가 된 느낌...) 다들 생각이 다르다 보니 팀원들 간의 회의를 진행할 때도 의견 충돌이 잦았다.
결국 다시 공부를 진행한 후에 event storming을 진행하게 되었고 이를 바탕으로 aggregate를 뽑아내면서 DDD를 적용하면서 패키지 구조를 재정립할 때 매우 수월했다. 이게 event storming을 하면서 느낀 가장 큰 장점인 것 같다. (이미 event storming을 하면서 설계가 진행되는 분위기) 추가로 event storming을 하는 과정이 평소에 하던 회의와 비교해서 굉장히 동적인 활동이기 때문에 재미도 있었던 것 같다. 처음에 프로젝트를 시작하기 전 한번쯤 시도해보는 걸 추천한다!
도움받은 사이트
https://virtualddd.com/learning-ddd/ddd-crew-eventstorming-glossary-cheat-sheet
https://10consulting.com/2019/05/02/domain-driven-design-and-event-storming-workshop/
