이벤트 스토밍

도메인을 빠르게 익히기 위해 하는 과정
도메인 지식의 상향 평준화가 목표, 서로 배우는 것이 중요함.
이벤트 스토밍은 기록 및 관리하려고 하면 안됨. 그냥 워크샵에서 끝내는게 좋음. -> 유지보수 하려고 하는 대상으로 만들지 않아야 함.
준비물
- 큰 회의실, 종이, 포스트잇 마커펜
- 실제 문제 해결에 관련된 모든 사람(질문이 있는 사람) -> 해당 도메인 전문가 느낌.
- 교육이나 회의를 리드하는 사람(진행자)
진행방법
- 벽에 커다란 종이를 붙여 놓고 포스트잇(도메인 이벤트 중심)을 붙여 나간다
  - 도메인 이벤트 설명은 혼란스러운 탐험의 도메인 이벤트 설명을 참조.
- 비즈니스 프로세스를 이해하는 데에 초점을 맞춘다.
- 모든 사람의 생각을 허용하고 존중한다.

각자 알고 있는 도메인 이벤트를 작성하도록 요청한다. (예를 들면, “전자계약서가 생성됨” 과 같은)
작성한 이벤트는 볼 수 있지만, 토론을 시작하지 말고 자신이 옳다고 생각하는 방식으로 기록한다. (일단, 남이 적은게 틀렸던 말던 신경쓰지 말고 생각대로 막 적기)
중복되던 말던 일단 자신이 떠오르는 이벤트를 마구잡이로 적는 단계
도메인 이벤트 - 주황색
- 도메인 전문가가 관심이 있는 어떤 사건
- 이벤트 이름은 과거에 일어났던 일이기 때문에 과거시제 이용
- 이벤트가 발생했다는것은 상태가 변경되었다는 것을 의미한다.
타임라인 적용
- 시간별로 왼쪽 -> 오른쪽으로 이벤트를 적는다.
- 위, 아래와 같이 수직적인 것은 같은 시간을 의미
핫스팟 (빨간색 포스트잇)
- 타임라인을 적으면서 발생한 갈등을 시각화하고 캡쳐하는데 사용
- 당장 5분 이상 토론하지 않는다. (나중에 티켓으로 등록하여 처리)
액터와 시스템 (분홍색 포스트잇)
- 단순한 “사용자” / 고객 보다 구체적인 페르소나를 설정한다.
  - 예를 들면 “업주” -> “XX 상품에 가입한 업주”
- 외부 시스템(AWS 등등) 부터 일부 레거시 및 마이크로서비스에 이르기까지 책임을 전가할 수 있는 모든 것

주로 ‘~할 때마다’ 라는 단어로 시작한다.
- ‘~ 정책(Policy)에 따르면 ~을 한다(Command)’
- 강사가 강의를 생성하면 강의 정책에 따라 미션이 생성된다.

시스템이 기대하는 책임을 수행하며 일관성을 유지하는 단위
- 수강생 수는 XX 명을 넘을 수 없다.
일관성은 항상 참이어야 하는 속성을 유지함으로써 달성된다.
- 동시성으로 인해 넘을 수도 있음. 하지만 비개발자는 이유를 알 수 없어서 이벤트 스토밍과정에서 이런 이유를 설명해주고 이를 불변으로 설정해야 함.

위의 순서대로 보통은 진행된다고 한다.

같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다른 경우가 있다.
명백한 언어 불일치는 종종 동일한 프로세스내에서 여러개의 바운디드 컨텍스트를 나타내는 지표이다. -> 누군가는 상품을 “A” 라고 하고 누군가는 “B” 라고 할 경우 경계를 긋고, 여기서는 상품을 “A” 라고 하고 여기서는 “B” 라고 하자 라고 하는 것.
예를 들면 특정팀은 주문이라는 것을 포괄적으로 말하지만, 특정 팀에서는 포장주문 / XX 주문등으로 나뉨. 이 경우 경계를 광고가 아닌 경계를 구분지어 포장주문 / XX 주문으로 나누어 말함. 이 구분 지은 경계(바운디드 컨텍스트) 에 따라서 팀이 분리되거나 도메인 모델이 분리됨.

#workshop-woowahan #week1