event-storming.md

이벤트 스토밍

이벤트 스토밍 정의

• 도메인 전문가와 개발자를 학습 과정에 참여시키기 위한 빠른 설계 기술
• 비즈니스 및 비즈니스 프로세스에 중점을 둔다.
  • 클래스와 데이터베이스가 아닌 이벤트와 비즈니스 프로세스에 중점을 둔다.
• 코드를 없애고 모든 사람을 동일한 수준으로 만드는 시각적인 접근

준비물

• 큰 회의실, 커다란 종이, 수 많은 포스트잇과 마커펜
• 실제 문제 해결에 관련된 모든 사람(질문이 있는 사람, 답이 있는 사람)
• 퍼실레이터(진행자)

이벤트 스토밍 진행 방법

• 벽에 커다란 종이를 붙여 놓고 그 위에 포스트잇을 붙여 나간다.
• 비즈니스 프로세스를 이해하는 데에 초점을 맞춘다.
• 이벤트 스토밍의 가치는 단순히 포스트잇을 벽에 붙이는 것이 아니라 커뮤니케이션이다.
• 노안인 분을 위해 글은 크게 쓰자.
• 볼펜은 가급적 번지지 않는 것으로 쓴다.

DOMAIN EVENT

• 도메인 전문가가 관심을 가지고 있는 어떤 사건
• 이벤트가 발생한다는 것은 상태가 변경됐다는 것을 의미한다.
  • 때문에 과거형으로 기록한다.
  • "블로그 글을 조회한다." 가 이벤트가 될 수 있는가?
  • 이것 역시 문맥(맥락)에 따라 이벤트가 될 수도, 아닐 수도 있다.
  • 조회한 뒤에 후속조치가 있냐 없냐에 따라 이벤트냐 아니냐가 결정된다.
• 보통 '~할 때', '~가 발생하면', '만약 ~하면'과 같은 요구사항은 도메인의 상태 변경과 관련된 경우가 많고 이런 요구사항을 이벤트를 이용해서 구현할 수 있다.

COMMAND

• 이벤트가 발생하는 원인

AGGREGATE

• 데이터 오너십
• 독립적인 라이프사이클
• 독립적인 확장성
• 보통 AGGREGATE을 기준으로 BOUNDED CONTEXT를 나눈다.

도메인 이벤트 - 주황색 포스트잇

• 도메인 전문가가 관심이 있는 어떤 사건
• 이벤트 이름은 과거에 일어났던 일을 표현하기 때문에 과거 시제를 사용한다.
• 이벤트가 발생한다는 것은 상태가 변경되었다는 것을 의미한다.

1단계 : 혼란스러운 탐험

• 각자가 알고 있는 도메인 이벤트를 작성하도록 요청한다.
• 각자가 작성한 이벤트는 볼 수 있지만, 토론을 시작하지 말고 자신이 옳다고 생각하는 방식으로 기록한다.

2단계 : 타임라인 적용

• 모든 도메인 이벤트를 올바른 타임라인으로 정렬하고, 실제로 중복되는 이벤트를 제거한다.
• 시간은 왼쪽에서 오른쪽으로 흐르고, 위에서 아래로 평행한 시간을 표현할 수 있다.

핫스폿

• 핫 스폿. 2단계에서 발생한 갈등을 시각화하고 캡처하는데 사용한다.
• 당장은 토론하지 않는다. 나중에 문제가 해결되면 제거한다.
• 문제를 해결하는게 이벤트 스토밍의 목적이 아니다. 도메인 지식을 맞추는게 목적이다.
• 그래서 나중에 해결을 위해 캡쳐해두는 것.

액터와 시스템 - 노란색과 분홍색

• 액터: 단순한 사용자 또는 고객이 아닌 구체적인 페르소나 설정
• 시스템: 외부 시스템부터 일부 레거시 및 마이크로 서비스에 이르기까지 책임을 전가할 수 있는 모든 것

바운디드 컨텍스트

• 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있다.
• 명백한 언어 불일치는 종종 동일한 프로세스 내에서 여러 개의 바운디드 컨텍스트를 나타내는 지표이다.

넥스트 스탭에서는 강의 컨텍스트를 나누면서 아래와 같은 그림이 그려졌다.

애그리게잇 또는 비즈니스 규칙 - 연노란색

• 시스템이 기대하는 책임을 수행하며 일관성을 유지하는 단위
• 일관성은 항상 참이어야하는 속성을 유지함으로서 달성된다.

참고하는 규칙

• 꼭 이대로 할 필요는 없다. 참고만 하자.
• 중요한 건 모두가 동일한 이해를 갖는 것.

특징

• 혼자 하는 것보다 다 같이 하는 것이 빠르다.
• 구현 코드보다 포스트잇을 변경하는 것이 훨씬 저렴하다.
• 대화에서 얻은 지식을 사용하여 비즈니스 프로세스 자체를 보다 잘 이해하고 개선한다.
• 팀이 비즈니스(소위 도메인이라고 불리는)와 코드로 나타내어지는 모델의 차이를 이해하고 수정하도록 돕는 것이 중요하다.
• 가장 일반적으로 발생하는 문제는 도메인 모델로 개발되어진 프로그램이 도메인 전문가들이 생각하고 있던 것과는 거리가 멀다는 것

역할 - 사용자

• 사용자
  • 불특정 다수의 소프트웨어 사용자
  • 애플리케이션에 대한 요구 사항을 가지고 있다.
• 도메인 전문가
  • 소프트웨어 프로젝트에서 자신의 활동 범위가 소프트웨어 개발이 아니라 애플리케이션 도메인인 구성원
  • 단지 불특정 다수의 소프트웨어 사용자가 아니라 주제 영역에 관해 깊이 있는 지식을 갖추고 있음
  • 도메인을 이해하는 데 부자연스럽고 부정확한 용어나 구조에 대해 반대 의사를 표명해야 한다.
• 개발자
  • 소프트웨어 프로젝트에서 자신의 활동 범위가 소프트웨어 개발인 구성원
  • 시스템을 서술적이고 기능적인 용어로 이해하고 토론할지는 모르지만 전문가들의 언어에 담긴 의미는 알지 못한다.
  • 개발자는 설계를 어렵게 만드는 모호함과 불일치를 찾아내는 데 촉각을 곤두세워야 한다.
• 자산화
  • Miro

---

규칙들이 있다는 것에 대해서만 알고만 있고, 얽매이지 말고, 상황에 맞게 이벤트 스토밍을 진행하면 된다. 이벤트 스토밍 후

• 모두가 서로에게 배운다.
• 모두가 서로 소통한다.
• 자신의 관점에서 문제를 발견하면 누구나 말할 수 있다.
• 모두가 문제를 해결하는 방법에 대한 자신의 아이디어를 제공한다.
• 워크숍 후 모두가 같은 사실을 알게 된다.
  • 도메인 지식 상향 평준화

이벤트 스토밍은 형상관리를 하는게 목적이 아니다. 지속해서 관리하고 어딘가에 관리하는 건 의미가 없다. 모두가 도메인 지식을 상향 평준화하는게 목표기 때문 새로 도메인 지식을 이해하는 사람이 있다면? 이벤트 스토밍을 또 하는게 낫다. (물론 주기가 너무 짧을 땐 결과물을 공유하는 것도 방법)

용어를 관리해야한다면? 용어사전을 따로 만든다.

모듈을 DDD 단위로 나누고, DDD 단위로 나뉜 모듈의 README.md 파일에 용어사전을 관리하는 것도 방법