DDD - 이벤트 스토밍

in DEV on DDD, Event-storming


이 포스트에서는 효과적으로 지식을 공유하고, 공동의 이해를 구축하며, 소프트웨어를 설계하기 위한 저차원적인 워크샾인 이벤트 스토밍에 대해 알아본다.
이벤트 스토밍은 도메인 지식을 발견하고, 유비쿼터스 언어를 개발하는 과정을 간소화하는 활동이다.
이벤트 스토밍은 간단한 도구 또는 적은 비용으로 빠르고 쉽게 반복 수행하여 목적을 달성하는 접근법인 로우테크 모델링 과정이다.

  • 이벤트 스토밍의 진행 과정
  • 이벤트 스토밍 워크숍 진행 방법
  • 이벤트 스토밍을 활용하여 도메인 지식을 공유하고, 유비쿼터스 언어를 구축하는 방법

목차

1. 이벤트 스토밍이란

이벤트 스토밍은 사람들이 모여 비즈니스 프로세스에 관해 브레인스토밍을 하고 신속하게 모델링하기 위한 로우테크 활동이다. (= 비즈니스 도메인 지식을 공유하기 위함)

이벤트 스토밍은 참가자가 다룰 비즈니스 프로세스가 있다.
참가자는 포스트잇으로 도메인 이벤트를 시간의 흐름에 따라 표현한다.
모델의 모든 구성 요소가 비즈니스 프로세스의 작동 방식을 설명할 때까지 단계별로 액터, 커맨드, 외부 시스템 등의 개념을 모델에 추가해가며 개선한다.

2. 이벤트 스토밍 참석자

이벤트 스토밍 워크숍은 엔지니어, 도메인 전문가, 제품 소유자, 테스터, UI/UX 디자이너, 지원 담당자 등 누구나 참석 가능하다.
다양한 배경을 가진 사람이 많이 참여할수록 더 많은 지식이 발견된다.

단, 참가자의 규모가 너무 크면 모든 참가자가 과정에 기여하는 것이 어려워지므로 10명 이하로 하는 것을 권장한다.

3. 이벤트 스토밍에 필요한 것

  • 모델링 공간
    • 종이로 덮인 벽 전체가 가장 좋음
  • 포스트잇
    • 색깔이 다양한 많은 양의 포스트잇
    • 모든 참가자가 자유롭게 메모를 추가할 수 있어야 함
  • 마커
    • 포스트잇에 적을 때 쓸 마커
  • 간식
    • 일반적으로 이벤트 스토밍은 2~4시간 정도 진행하므로 에너지 보충을 위한 간식이 필요함
  • 회의실
    • 넓은 회의실
    • 참가자가 자유롭게 이동하고 모델링 공간을 관망할 수 있도록 회의실 가운데 큰 테이블을 두지 않음
    • 참가자가 구석에 앉아있지 않고 활발하게 세션에 참여하고 지식을 공유할 수 있도록 의자도 가능하면 회의실 밖으로 치움

4. 이벤트 스토밍 과정

4.1. 1단계: 자유로운 탐색

이벤트 스토밍은 탐색하려는 비즈니스 도메인에 관련된 도메인 이벤트를 브레인스토밍하는 것으로 시작한다.
도메인 이벤트는 이미 발생한 일을 설명하므로 과거형으로 작성한다.

이 단계에서 모든 참가자는 오렌지색 포스트잇에 무엇이든 떠오르는 도메인 이벤트를 적어서 모델링 공간에 붙인다.

초기 단계에는 이벤트의 순서나 중복에 신경쓰지 않아도 된다.

새로운 이벤트가 추가되는 속도가 현저히 느려질 때까지 계속해서 도메인 이벤트를 생성한다.

자유로운 탐색

4.2. 2단계: 타임라인

생성된 도메인 이벤트를 읽어보고 비즈니스 도메인에서 발생하는 순서대로 정리한다.

정상 시나리오부터 시작하며, 정상 시나리오가 끝나면 다른 시나리오를 추가한다.
예) 에러 발생 시 경로, 다른 비즈니스 의사 결정 시

분기 흐름은 이벤트에서 2개의 흐름이나 또는 화살표로 표현한다.

분기 흐름

4.3. 3단계: 고충점

전체 구성을 보고 프로세스에서 주목할만한 포인트를 식별한다.
예) 병목 구간, 자동화가 필요한 단계, 문서나 도메인 지식이 없는 경우

이런 포인트로 쉽게 돌아오거나 나중에 다시 다룰 수 있도록 이렇게 비효과적인 것들은 명확하게 표시하는 것이 좋다.
고충점은 핑크색 포스트잇을 돌려서 다이아몬드 형태로 표시한다.

아래는 예약 프로세스에서 항공권 요금이 어떻게 비교되는지에 관한 도메인 지식이 사라진 부분을 고충점으로 표시한 예시이다.

프로세스에서 주목할만한 관점을 표시

4.4. 4단계: 중요 이벤트

컨텍스트가 바뀌는 것을 나타내는 중요 이벤트인 중대한 비즈니스 이벤트를 찾는다.
중대 이벤트 전후로 세로로 선을 긋는다.

아래는 주문 과정에서 발생하는 중요한 상황 변화를 나타내는 예시이다.
예) 쇼핑 카트가 초기화됨, 주문이 생성됨..

컨텍스트 변경을 나타내는 중요 이벤트

중요 이벤트는 나중에 바운디드 컨텍스트의 후보가 된다.

4.5. 5단계: 커맨드

도메인 이벤트가 이미 발생한 것을 설명하는 반면, 커맨드는 무엇이 이벤트나 이벤트 흐름을 시작하게 하는지를 설명한다.
따라서 과거형이 아닌 명령형으로 작성한다.
예) 캠페인을 게시한다, 트랜잭션을 롤백한다..

커맨드는 파란색 포스트잇으로 작성하며, 커맨드가 생성하는 이벤트 앞에 붙인다.
특정 역할을 담당하는 액터가 특정 커맨드를 실행한다면 액터 정보는 노란색 포스트잇에 적어서 붙인다.

모든 커맨드가 액터와 연관되는 것은 아니다.

고객(액터)가 주문을 제출한다(커맨드)를 실행한 후, 주문이 생성됐다 등의 이벤트가 생성됨

4.6. 6단계: 정책

대부분 커맨드에는 관련된 액터가 없다.
정책 단계에서는 커맨드를 실행할 수 있는 자동화 정책을 찾는다.

자동화 정책은 이벤트가 커맨드의 실행을 시작하는 시나리오로, 커맨드는 특정 도메인 이벤트가 발생할 때 자동으로 실행된다.

정책은 보라색 포스트잇에 적어서 이벤트와 커맨드를 연결한다.

배송이 승인됐다(이벤트)가 나타날 때 주문을 배송한다(커맨드)를 실행하는 자동화 정책

만일 어떤 의사결정 조건이 만족할 때난 커맨드를 시작해야 한다면 그 의사결정 조건을 정책 포스트잇에 명시한다.
예) ‘불만이 접수됐다’ 이벤트 이후에 ‘상부 보고’ 커맨드를 시작해야 하지만 VIP 고객일 때만 상부 보고를 하는 경우라면 ‘VIP 고객에 한함’ 이라는 조건을 정책 포스트잇에 기재함

모델링 공간에서 이벤트와 커맨드가 멀리 떨어져있다면 화살표를 그려서 연결한다.

4.7. 7단계: 읽기 모델

읽기 모델은 도메인에서 액터가 커맨드를 실행하는 의사결정을 내릴 때 사용하는 시각적 데이터이다.

읽기 모델은 녹색 포스트잇에 액터의 의사결정을 도울 때 필요한 정보의 원천에 대해 짧게 기재한다.
액터가 이 읽기 모델을 참고하여 커맨드를 실행하므로 커맨드 앞에 읽기 모델을 둔다.

고객(액터)이 주문(커맨드)을 제출하는 의사결정을 위해 필요한 쇼핑카트(읽기 모델) 뷰

4.8. 8단계: 외부 시스템

여기서는 외부 시스템 연동 정보를 보강한다.
탐색 중인 도메인에 포함되지 않은 모든 시스템은 외부 시스템에 해당한다.
외부 시스템은 커맨드를 실행할 수도 있고(입력), 반대로 알림 이벤트로 만들어서 외부 시스템으로 전달할 수도 있다.(출력)

외부 시스템은 핑크색 포스트잇으로 표시한다.

아래는 CRM(외부 시스템)이 주문을 배송한다(커맨드)의 실행을 시작하고, 배송이 승인되면(이벤트) 정책을 통해 CRM(외부 시스템)과 통신하는 예시이다.

커맨드의 실행을 시작하는 외부 시스템과 외부 시스템에 전달되는 이벤트의 승인

4.9. 9단계: 애그리거트

모든 이벤트와 커맨드가 표현되면 애그리거트의 개념을 포함하여 모델을 구성할 수 있다.
애그리거트는 커맨드를 받아서 이벤트를 생성한다.

애그리거트는 커다란 노란색 포스트잇으로 기재하고, 왼쪽에 커맨드를 두고 오른쪽에 이벤트를 둔다.

애그리거트에 구성된 커맨드와 이벤트

4.10. 10단계: 바운디드 컨텍스트

이제 서로 연관된 애그리거트를 찾는다.
애그리거트의 그룹은 바운디드 컨텍스트 경계의 후보가 된다.

시스템을 바운디드 컨텍스트로 분리

5. 변형

이벤트 스토밍의 진행 과정을 반드시 따라야하는 것은 아니다.
상황에 잘 맞게 진행 과정에 대해 자유롭게 변형을 해도 좋다.

이벤트 스토밍이 끝나면 도메인 이벤트, 커맨드, 애그리거트, 바운디드 컨텍스트 후보를 포함한 모델을 얻게 된다.
뿐만 아니라 다양한 이해관계자 간의 지식 공유, 비즈니스와 멘탈 모델의 일치, 충돌 모델 발견, 유비쿼터스 언어 구축을 할 수 있다.

6. 이벤트 스토밍을 사용하는 경우

  • 유비쿼터스 언어 구축
  • 비즈니스 프로세스 모델링
  • 새로운 비즈니스 요구사항 탐색
  • 도메인 지식 복구
  • 기존 비즈니스 프로세스의 개선 방법 탐색
  • 새로운 팀원의 훈련

7. 진행 팁

이벤트스토밍을 처음 해보는 그룹을 대상으로 진행할 때는 시작할 때 진행 개요를 빠르게 소개한다.
참가자들이 이벤트, 커맨드, 액터 등 모델링 요소에 부여된 색을 기억하기 쉽게 포스트잇을 사용하여 워크샵이 진행되는 동안 모든 참가자들이 볼 수 있게 붙여둔다.

그룹 활동의 활발함이 떨어지면 질문을 던져서 과정을 돕거나 워크숍의 다음 단계로 넘어갈지를 결정한다.
이벤트 스토밍은 집중적인 활동이기 때문에 휴식이 필요한데, 휴식 후 다시 시작할 때는 회의실에 모든 참가자가 돌아오기 전까지는 시작하지 않는다.
시작할 때는 현재까지 진행된 모델링을 리뷰해서 모든 참가자가 협력적인 모델링 분위기로 돌아오도록 돕는다.

이벤트 스토밍은 대면으로 하는 것이 가장 효과적이지만, 그렇지 못할 경우 miro.com 이라는 서비스를 이용하는 것도 괜찮다.
원격 이벤트 스토밍은 참가자의 수가 적을 때 더욱 효과적이다.
대면 이벤트 스토밍은 10명 정도 참가가 가능하지만, 원격 이벤트 스토밍은 5명 정도로 제한하는 것이 좋다.
더 많은 참가자가 지식 공유를 해야한다면 세션을 나누어서 진행한 후 각각의 결과를 비교해서 취합된 모델을 만든다.

정리하며..

  • 이벤트 스토밍은 협업을 통해 비즈니스 프로세스를 모델링하는 워크숍임
  • 도출된 모델 외에 지식 공유라는 이점을 얻을 수 있음

참고 사이트 & 함께 보면 좋은 사이트

본 포스트는 블라드 코노노프 저자의 도메인 주도 설계 첫걸음을 기반으로 스터디하며 정리한 내용들입니다.




© 2020.08. by assu10

Powered by assu10