소리치는 아키텍처 - 개발공정 - 이벤트스토밍

### 목차
- [(서문) 개발공정](https://ohhoonim.blogspot.com/2024/02/blog-post_62.html)
- [1. 이벤트스토밍](https://ohhoonim.blogspot.com/2024/02/blog-post_47.html)  <- 현재문서
- [2. 유스케이스 구현](https://ohhoonim.blogspot.com/2024/02/blog-post_92.html) 
- [3. 인프라 테스트](https://ohhoonim.blogspot.com/2024/02/blog-post_39.html) 
- [4. UI 구현](https://ohhoonim.blogspot.com/2024/02/ui_21.html)
## abstract
이벤트스토밍은 요구사항에서 유스케이스를 도출하는 과정이다. 때에 따라 고객의 요구사항이 개괄적이어서 유스케이스를 도출하기 어려운 경우에도 이벤트스토밍을 통해 유스케이스를 발견해낼 수 있다. 이벤트 스토밍은 기본적으로 bottom-up 방식으로 동작하지만 top-down방식으로 유스케이스를 도출할 수도 있다. 
이 공정에는 프로젝트 관련자 모두가 참석해야하는 것이 원칙이지만, 그렇지 못한 경우라도 실무 담당자와 유스케이스 설계 구현자는 반드시 참석해야한다. [^1]

[^1]: 이 문서에서 “설계 구현자”는 일반적으로 “설계자”라고 불리는 PL급 개발자를 의미하며, “개발자”라 함은 ”[[인프라 테스트]]“ 공정의 코드 생성자를 의미한다.
## tool
- 포스트잇과 펜 그리고 그것을 붙여놓을 넓은 보드
- 디지털 환경이 잘 되어있다면 그것을 대체할 수 있는 아무거나 다 됨. 단, 온라인 보다는 오프라인으로 진행하는 것을 권장함.
- 포스트잇은 최소 3가지 색상을 준비[^포스트잇]하고, 각 색상에 대해 참석자들은 그 의미를 숙지한다.
	- 파랑색 : command
	- 노랑색 : event
	- 빨강색 : 외부 시스템
	- 하얀색(옵션) : 페르소나(가상 사용자)
	- 초록색(옵션) : 비지니스 룰

![이벤트스토밍 색깔별 역할](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzB53vE93lF0vJSljr5M7POcQPeqG3Mio8JjdjAYS_RSsliO7JmQ4fWmkqMGw_KQBVAQL1YsPhmC8bT8ZN2dJ2FkodiXfWJu0X6Qokz4p8BjshpbgaMqCEC7Tp6uQZND0oOutRUh-9MEBs8wWmBna8YisJuXPSELm3wVUeJj0z5OPrGpCkpS3-cDqnZIs/s320/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-02-21%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%207.06.06.png)

- 보드는 좌측에서 우측으로 시간이 진행됨을 의미하며, 완성된 구현 화면을 상상하지 말고 현재 수행하고 있는 비지니스 업무 흐름을 중심으로 포스트잇을 나열해나간다. 
- 이벤트는 과거형으로 표현한다.
- 예외 처리를 포스트잇으로 표현하면 상당히 복잡해지므로 ‘초록색’을 이용하여 비지니스 룰을 정의하는 식으로 진행한다. 
- 하나의 업무에 대한 이벤트 스토밍이 마무리 되면 충분한 휴식 시간을 부여하여, 구성원간 좀 더 많은 대화가 이루어지도록 한다.
- 포스트잇은 누구나 붙였다 뗏다를 할 수 있다.

[^포스트잇]: 옵션색상은 처음엔 필요하지 않지만 이벤트스토밍을 진행하다보면 꽤 유용하게 활용된다.
## activity
- 진행자는 시작전 tool 사용법에 대해 간단한 브리핑을 진행한다. 
- 아래 사항들을 반복 수행한다.
	- 진행하려는 주제업무에 대한 주요 임무자를 지정한다. 
	- 지정된 임무자는 해당 업무에 대해 포스트잇과 펜을 이용하여 시간 흐름순로 보드에 붙여나간다. 이때 다른 참석자들은 관여하지 않는다.
	- 임무자가 스토밍을 진행하는 동안 tool 사용법이 여의치 않는 경우 진행자는 적극적으로 도움을 준다.
	- 임무자의 역할이 끝나면 비지니스를 간단히 참석자들에게 설명하고 토론의 시간을 갖는다.
	- 특정 사용자에 대한 수행 조건이 필요하다면 비지니스 룰 보다는 페르소나를 사용한다. 
	- 비지니스 룰에 대한 협의가 필요한 사항이 발생하면 논쟁을 즉시 중단한다. 참석자들끼리 협의하지 않는다.
	- 확인이 필요한 사항은 최대한 즉시 확인하고, 불가능할 경우 반드시 확인할 담당자를 지정한다.
- 진행자는 이벤트스토밍 결과를 디지털화하고 참석자들에게 공유한다. 
- 이벤트 스토밍 이후, 업무 담당자는 누락된 비지니스 프로세스를 발견할 수 있다. 이러한 경우 업무 담당자는 이미 이벤트 스토밍을 경험해봤으므로 이벤트 스토밍 초안을 제시하고, 진행자 또는 의사결정권자가 추가 요구사항의 반영 여부를 결정한다.
## output
- 도메인
	- 비지니스 영역의 경계를 명확히한다. 영업, 구매, 생산, 재고 등
	- 업무영역의 유비쿼터스 언어를 정의한다.[^공통코드]
- 유스케이스
	- command(파란색)를 기준으로 유스케이스를 발견한다.
	- command가 연속적으로 진행이 되어야한다면 하나의 유스케이스로 묶어준다.
	- 외부시스템(빨간색)은 command가 될 수도 event 가 될 수도 있다. 
- 비지니스 룰
	- 유스케이스에서 발견된 다양한 룰을 기준정보로 관리될 수 있도록 도출한다.
	- 상세 룰을 도출하는 것은 [[유스케이스 구현]] 공정에서 발견한다. 
- 연계방식
	- 외부시스템과의 연계 방식을 결정한다. http, socket, 실시간, 배치 등

[^공통코드]: 일반적으로 소프트웨어 구현시 시스템간 통신시 정해진 코드를 사용하게 되는데 이를 공통코드라 한다. 공통코드는 식별을 하기위한 코드(바코드 등)와 시스템내 정합성 유지를 위한 코드(창고번호 등)로 구분을 할 수 있다.

## 구현사례
[YOUTUBE](https://youtu.be/uocEsOuvfwk)