[221001] Event Storming - 1

http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html

이벤트스토밍은 복잡한 비즈니스를 빠르게 탐색하기 위한 워크샵이다.

• powerful : 몇 주가 아닌 몇 시간만으로 완전한 비즈니스 흐름에 대한 포괄적인 모델을 만들 수 있다.
• engaging : 모든 아이디어는 질문을 가진 사람들과 답을 아는 사람들이 한 자리에 모여 함께 모델을 만든다.
• efficient : 결과로 만들어진 모델은 DDD스타일과 일치한다. 또 Context와 Aggregate 바운더리를 빠르게 결정할 수 있다.
• easy, fun : 그렇다고 한다.

1. 적절한 사람들을 초대 (Invite the right people) 큰 방에 모두 몰아넣는다.
2. 모델링을 위한 무제한적인 공간을 제공 (Provide unlimited modeling space) 큰 화이트보드가 좋다. 없다면 페이퍼롤. 없다면 miro.
3. 도메인 이벤트로 도메인을 우선 탐색한다 (Explore the domain starting from Domain Events) 도메인 이벤트는 도메인에서 발생한 의미있는 무엇(이벤트)을 말함. 타임라인에 따라 모델링 표면에 모두 배치한다.
4. 도메인 이벤트의 기원을 탐색한다 Explore the origin of Domain Events
   • 유저액션의 직접적인 결과 -> 파란색 스티커(Command)
   • 외부 시스템에서 일어난 일이거나 시간이 흐른 결과인 경우 - 보라색 스티커
   • 다른 이벤트의 직접적인 결과 -> 두 이벤트를 가깝게 배치한다

5. Aggregate를 찾는다 (Look for Aggregates) 코드에서 시작하여 Aggregate를 정의하는 대신, outside-in방식으로 접근한다. Aggregate는 Command를 수신하고 실행여부를 결정하여 도메인이벤트를 생성하는 시스템의 한 부분(portion of system)이다.

   DDD Aggregate는 단일단위로 처리될 수 있는 도메인 객체(objects)들의 무리를 말함(https://martinfowler.com/bliki/DDD_Aggregate.html)

지금까지가 기본단계이다. 그러나 토론이 뜨거워지면 몇가지 보너스 목표를 발견한다. 여기 기본경로에서 우회할만한 보너스 타겟의 목록(선택지)가 있다.

1. 하위 도메인 탐색 (Exploring Subdomains) 일분 도메인 전문가는 자신의 분야에서 더 많은 전문지식을 보여주고, 다른 부분은 다른 사람들에게 맡겨버린다. 이런 다른 책임 영역(Different areas of responsibility)들은 하위 영역에 잘 매핑됨.

2. 경계에 있는 컨텍스트 탐색 (Exploring Bounded Contexts)

   토론 중에 갈등이 일어나는 영역이 있을 수 있다. DDD사고 방식을 가진 개발자와 퍼실리테이터(facilitators - 회의 구성원간 상호작용을 촉진하여 목적을 달성하도록 돕는 전문가)는 용어에 대한 다양한 해석을 발견할 것이다. 이것은 아주 귀중한 정보이다. 버리지 마라. 작은 노란색 스티커로 페르소나(personas)를 포함하도록 표기법을 확장할 수도 있다.

3. 주요 인수 테스트 스케치 (Sketching Key Acceptance Tests)

   논의가 코너 케이스 혹은 모호한 시나리오를 중심으로 공회전하기 시작하면 명확한 인수 테스트를 정의한다. (모호성이 사라진다)

   인수 테스트 : 시스템이 실제 운영 환경에서 사용될 준비가 되었는지 최종적으로 확인하는 단계이다. 시스템 검사는 사용자가 평가하고 관리자가 점검한다.

   참고 : 한국 위키피디아에서 [Management information System 12/E] 를 인용함. https://ko.wikipedia.org/wiki/%EC%9D%B8%EC%88%98_%EA%B2%80%EC%82%AC

4. 주요 읽기 모델 아티팩트 스케치 (Sketching Key Read Model Artefacts)

   일부 시나리오는 시스템이 수행하는 것보다 사용자가 보는 행위가 더 중요할 때가 있다.

   특히, 특정 사용자를 위해 가치 있는 화면, 표 또는 그래프가 있는 경우다. 스티커에 간단하게 스케치하고 Command 스티커에 가깝게 배치한다.

모든 걸 다 넣으려고 하지 마라. 이 워크숍의 목표는 짧은 시간에 최대한 많은 것을 배우는 것이라는 점을 명심하라. 우리는 주요 인물들을 워크샵에 초대했고, 그들의 시간을 낭비하고 싶지 않다.

따라서 이러한 보너스 목표에 들어서면, 가장 효율적으로 시간을 사용할 준비를 해놓아야한다. 귀중한 힌트를 얻어 스케치한 스티커를 핫스팟으로 배치한다.

모델 완성도에 대한 논의는 유도하지 말아라. 이 모델은 더 거창해질 것이므로, 지금 완성하려고 하는 것은 가치가 없거나 일부 참가자들에게는 무섭게 들릴 수 있다.

불완전함을 포용하는 것이 워크숍을 덜 지루하고 더 유익하게 만들 것이다.

알다시피 워크샵에는 단일 형식은 없다. 사실 첫 번째 단계는 거의 동일하지만, 참여자의 프로젝트 범위에 따라 형식이 다를 수 있다.

DDD 실무자들은 재미뿐만 아니라 결과모델이 그들에게 필요로 하는 것에 훨씬 가깝기 때문에 이 접근방식을 좋아한다. (이것을 데이터 모델이 아니다!)

The resulting model is fully behavioral: 구현을 본질적으로 제한하는 기본 데이터 모델이 없다. 만약 Command-Query Responsibility Separation에 관심이 있다면, 워크샵 시도이후 나에게 맥주를 권해야 하는 절박함을 경험하게 될 것이다. (아마 많은 도움을 얻었을 거라는 생각인듯)

당신은 또한 짧은 시간에 코딩을 시작하여 검증할 수 있다. 이것이 대부분의 생산적인 팀이 하는 일이며, 토론 기반 탐험(discussion-based discovery)과 도메인 기반 구현(Domain-Driven oriented implementation)을 결합하면 엄청난 개선을 가져올 수 있다.

You'll be basically implementing the right thing faster. 기본적으로 올바른 것을 더 빨리 구현한다.

• 적절한 공간 (suitable room) : 조용하고 큰.
• 쓸 수 있는 표면 (writable surface) : 이케아 페이퍼롤 같은거
• 많은 스티커 (a LOT of sticky notes) : 기본 세트 - 옅은 노란색, 주황, 파랑, 보라색 직사각형 스티커 (+ 개인적으로 핫스팟용 빨강이 필수)
• 마커 (working markers) : 참가자당 하나와 백업
• 만일을 대비한 마스킹 테이프
• 올바른 사람들 (right people)
• 퍼실리테이터 (facilitator)

다스베이더 같은 상사를 참여시키기 전에 샌드박스에서 실행하기 위한 프로토타입을 만들고 싶을 수 있다. (일부 사용자 그룹은 이에 완벽하다. 그들은 실험을 좋아한다.)

혹자는 퍼실리테이터(진행자)를 고용하여 회사 워크샵을 운영하면서 워크샵 자체 및 가능한 추가 지침을 제공할 수 있다.

필자는 이후 이벤트스토밍을 개선한다.

모델스토밍이라고 한다. https://www.slideshare.net/ziobrando/model-storming

Model Storming은 지금 적용하고 있는 것보다 더 일반적인 접근방식이며, 이벤트스토밍은 이중 가장 주목할만한 구현이다.

즉, 내 생각에 필자의 모델스토밍은 왜 이벤트스토밍이 효과적인이 구조를 추상화하는 시도인 것으로 보인다.

• 이벤트스토밍에 있는 문헌들 : https://www.eventstorming.com/resources/