◆ 이벤트 스토밍을 통한 마이크로서비스 도출
▶ 마이크로서비스 간의 의존성을 줄이기 위해서는 아키텍처 영역에서 언급했다시피 서비스 간 비동기 메시지 기반 도메인 이벤트를 활용하는 것이 중요한데 이러한 도메인 이벤트를 통한 의존 관계를 식별하는 방법이 쉽지 않은데 이를 위해 알베르토 브란돌리니(Alberto Brandolini)라는 이탈리아 출신의 DDD 컨설턴트가 DDD 설계를 가속화할 수 있는 이벤트 스토밍(event storming)이라는 설계 기법을 고안해 냈는데 이벤트 스토밍은 이벤트 중심으로 이해 관계자들이 모여 브레인 스토밍하는 워크숍을 의미
▶ 이벤트 스토밍은 모든 이해 관계자가 모여 서로가 가지고 있는 각 관점을 논의하며 그 차이점을 이해하고 공유할 수 있다는 점에서 기존 방법론에서 장기간 단절하며 수행했던 요구사항, 프로세스 모델링, 설계를 진행하는 과정을 뛰어넘는 민첩성과 효율성을 보여주고 쉽고 간편한 도구를 사용해 빠른 시간 내에 지식 공유를 통한 협업을 가속화하고 시각화함으로써 서로간의 학습 및 탐색을 촉진하는 워크숍이라 할 수 있음
▶ 이벤트 스토밍의 개념
● 시스템의 액터(사용자 또는 역할자)는 원하는 바를 얻기 위해 시스템을 조작(커맨드)하고 이 조작은 시스템을 동작(도메인 이벤트)하게 하며 이 동작을 통해 사용자의 요청에 해당하는 데이터(읽기 모델)를 만들고 이 정보는 간단한 스케치 형태의 UI(사용자 인터페이스) 형태로 액터에서 제공되며 액터는 이 정보를 바탕으로 다시 시스템을 조작하고 또 시스템이 동작하는 절차를 반복
▶ 이벤트 스토밍 워크숍 준비
● 이벤트 스토밍 워크숍은 다양한 이해관계자의 지식을 공유하고 새롭게 도출된 아이디어를 표현하기 위한 목적으로 진행
● 워크숍을 진행하려면 다음과 같은 사항을 준비
⊙ 공간: 깨끗한 벽이 있는 넓은 워크숍 공간
⊙ 참가자: 고객, 도메인 전문가, 설계자, 개발자, 테스트 등 모든 이해 관계자
⊙ 준비물: 벽에 붙일 흰색 A0 전지, 마커 펜 다양한 색의 스티커, 선을 만들 수 있는 다양한 색깔의 라인 테이프, 스카치 테이프
⊙ 열린 분위기로 활동을 촉진하고 리딩할 수 있는 퍼실리테이터(facilitator)
● 워크숍 공간에 의자는 치우는 것이 좋은데 편하게 의자에 앉으면 워크숍에 적극적으로 참여하지 않게 되기 때문
● 워크숍 참여자는 적극적이고 긍정적이며 열린 마음가짐과 토론 및 대화를 주저하지 않는 용기를 갖고 참여하고 다른 참여자의 의견을 무시하거나 반박하기보다 토론을 통해 의견을 맞춰가는 것이 중요
● 준비물 중 마커 펜은 모든 참여자가 하나씩 가질 수 있도록 충분히 준비
● 워크숍 방식
⊙ 넓은 공간(벽이나 넓은 책상)에 여러 장의 흰색 전지를 이어붙여 설계 공간을 마련
⊙ 쉽게 접근 가능한 별도 공간에 다양의 색의 포스트잇과 기타 준비물을 올려 놓음
⊙ 모든 참가자가 마커펜을 하나씩 들고 설계 공간을 바라보게 함
⊙ 퍼실리테이터의 지시에 따라 워크숍을 진행하는데 모든 활동은 타임박싱으로 집중해서 몰입하도록 유도
● 스티커 유형별 의미
⊙ 도메인 이벤트 - 오렌지색(orange)으로 표현하는데 발생한 사건으로 과거 시제 동사로 표현
⊙ 커맨드 – 파란색으로 표현하는데 도메인 이벤트를 트리거하는 명령
⊙ 외부 시스템 – 핑크색으로 표현하는데 도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템
⊙ 액터: 작은 노란색으로 표현하는데 개인 또는 조직의 역할
⊙ 애그리거트: 노란색으로 표현하는데 도메인 이벤트 와 커맨트가 처리하는 데이터 상태가 변경되는 데이터
⊙ 정책: 라일락 색으로 표현하는데 이벤트 조건에 따라 진행되는 결정
⊙ 읽기 모델: 초록색으로 표현하는데 도메인 액터에게 제공되는 데이터
⊙ 사용자 인터페이스: 흰색으로 표현하는데 스케치 형태의 화면 레이아웃
⊙ 핫스팟: 자주색으로 표현하는데 의문, 질문, 미결정 사항
▶ 이벤트 스토밍 워크숍 진행
● 워크숍에서는 많은 사람이 모여 서로 소통하면서 스티커를 붙이는 활동을 수행하므로 체력 소모가 크고 2시간이 넘어가면 집중력이 떨어지므로 진행 시간은 최대 3시간을 넘지 않는 것이 좋은데 시간 내에 완료되지 않는 경우 하루나 이틀 후 추가 워크숍을 진행하는 것이 좋음
● 이벤트 스토밍은 다음과 같은 순서로 진행
⊙ 도메인 이벤트 찾기
⊙ 외부 시스템/외부 프로세스 찾기
⊙ 커맨드 찾기
⊙ 핫스폿 찾기
⊙ 액터(사용자/역할) 찾기
⊙ 애그리거트 정의하기
⊙ 바운디드 컨텍스트 정의하기
⊙ 컨텍스트 매핑하기
● 상품을 판매하는 사람과 구매하는 사람을 이어주는 쇼핑몰 서비스로서 판매자는 상품을 팔기 위해 쇼핑몰 서비스에 상품을 등록하고, 이 상품이 필요한 사람이 상품을 주문하면 판매자가 주문한 사람에게 상품을 발송하는 시스템
● 업무 흐름
● 워크숍 진행
⊙ 도메인 이벤트 찾기
→ 시간의 흐름에 따라 시스템의 동작을 의미하는 도메인 이벤트를 도출
→ 데이터나 데이터의 구조가 아닌 비즈니스 흐름에서 발생한 이벤트에 초점을 두는 것이 중요한데 참여자들이 각각 마커펜을 들고 오렌지색 포스트잇에 이벤트명을 작성해서 붙이면 되는데 이벤트명은 과거형 동사로 작성
→ 이벤트는 왼쪽에서 오른쪽으로 시간 흐름 순으로 붙이되 이벤트가 연쇄적으로 발생하는 경우 바로 옆에 붙이고 같은 시점에 비즈니스 조건에 따라 대체적으로 발생할 수 있는 이벤트는 세로로 아래쪽에 같은 선상에 붙임
→ 도메인 이벤트는 비즈니스의 어떤 상태를 생성, 변경, 삭제하는 요소
→ 시스템의 화면을 연상 하지 말고 비즈니스가 흘러감에 따라 비즈니스를 구성하는 요소들의 상태가 어떻게 변경되는지 생각
→ 이 시스템은 회원가입 후 사용할 수 있으므로 회원가입, 수정, 탈퇴 기능에 해당하는 도메인 이벤트인 [회원 가입됨], [회원정보 수정됨], [회원정보 삭제됨]을 도출
→ 쇼핑몰에서 도메인 이벤트 도출 – 회원 가입 후 상품이 등록되고 주문과 배송이 이뤄지는 과정을 이벤트로 파악
⊙ 외부 시스템 도출
→ 이벤트를 도출하면서 레거시 시스템이나 외부 시스템과의 연계를 통해 업무의 흐름이 진행될 때는 이 프로세스의 이름을 핑크색 스티커에 작성해서 이벤트의 오른쪽 상단에 붙이고 화살표를 그려 이 외부 시스템을 호출한다는 것을 표시
→ 시스템 구현 범위에 있는 기능이 아니더라도 시스템의 기능 구현을 위해 연계가 필요한 시스템들은 모두 도출
→ 시스템 이름을 명사 형태로 작성
→ 회원가입을 하거나 회원 정보가 수정될 때 회원 정보의 유효성을 판단하는 시스템과 연계하고 [주문 아이템 주문됨] 이벤트와 연계되는 외부의 [결제 시스템], [결제 승인됨] 이벤트와 연계되는 [이메일 시스템]이 도출
⊙ 커맨드 도출
→ 도메인 이벤트를 찾은 후에 이 이벤트를 동작하게 하는 커맨드(Command)를 찾음
→ 커맨드는 파란색 포스트잇에 작성하며 커맨드명은 도메인 이벤트를 동작하게 하는 것으로 명령형, 즉 동사 형태로 작성
→ 커맨드는 앞에서 식별한 도메인 이벤트를 보면 쉽게 유추할 수 있음
→ 하나의 커맨드에 의해 여러 개의 이벤트가 동시 또는 연속해서 발생할 수 있으며 조건에 따라 하나의 커맨드에 여러 개의 다른 이벤트가 발생할 수 있음에 유의
→ [회원 가입됨] 이벤트를 트리거하는 커맨드로 [회원가입]을 도출한 것을 볼 수 있음
→ [회원 가입됨] 이벤트를 동작하게 하는 [회원가입] 커맨드, [상품 등록됨] 이 벤트를 트리거하는 [상품등록] 커맨드 등 각 도메인 이벤트를 동작하게 하는 커맨드들을 도출
⊙ 핫스폿 도출
→ 워크숍을 진행하는 과정에서 의문 사항이 생기거나 참여하는 사람들이 결정하기 힘든 사항, 다 른 부서나 외부에 문의할 필요가 있는 사항과 같이 워크숍 중에 해결하거나 정의할 수 없는 것 들이 파악될 수 있는데 이러한 내용을 잊지 않고 기록하기 위해 눈에 잘 띄는 보라색 스티커에 가정, 경고, 질문, 미결정 사항 등을 작성해서 문제가 되는 위치에 붙이는데 이를 핫스폿이라 하며 워크숍이 진행되는 어느 시점에서라도 파악되는 대로 바로 워크숍 공간에 붙일 수 있음
→ [상품 주문 취소] 커맨드 옆에 [취소 가능 시점 확인]이라는 핫스폿을 붙일 수 있는데 이러한 핫스폿은 별도로 관리될 수 있는 사항에 해당
댓글