DEV Ocean Oepn Lap 2회차를 수행하면서 Event Storming 에 대해서 스터디를 했습니다.

이벤트 스토밍은 무엇인지에 대해서 이해하고,

간단한 예제를 확인하면서 이벤트 스토밍을 토이 프로젝트에 적용해보는 시간을 가져보았습니다.

참고: 내부 이미지들은 Miro에서 제공하는 이벤트 스토밍 보드를 참고하였습니다.

EventStorming

• EventStorming은 커뮤네케이션 브레인스토밍 방법으로, 특정 지식 (전문분야)에 대한 지식과 이해를 쿼크셥을 통해서 공동으로 개발하고 시각화 하는 방법이며,

  일명 도메인 이벤트를 도출하는 방법이다.

이벤트 스토밍 진행

• 사람: 6 ~ 10명의 사람

• 준비시간: 약 20분

• 수행시간: 3 ~ 6시간

참여자

• 이벤트 스토밍에 참여되는 사람은 다음과 같다.

• 무엇을 물어봐야할지 아는 사람: 보통 개발자, 개발팀, 테스터

• 이러한 질문에 답을할 수 있는사람: 비즈니스 익스퍼트, 프로덕오너, 클라이언트

• 이벤트 스토밍을 진행자: 스크럼 마스터, 애자일코치

준비사항

• 어떤 지식 영역을 모델링하거나, 이해하고 싶은지 확인하기

• 비즈니스 프로세스가 광범위할수록 이 방법에 더 많은 시간이 소요된다.

• 지식 영역을 더 작은 비즈니스 프로세스로 나누어 여러 이벤트를 통해 하나씩 모델링할 수 있는지 생각하기

• 예)

  • 지식영역: 온라인 상점 비즈니스

  • 프로세스: 매장 라이브러리/오퍼, 주문 프로세스등

• 중자재인경우:

  • 이벤트 스토밍 세션을 미리 중재하는 작업일 처리했는지 확인하기

용어:

• Domain Event: (오렌지 스티커)

  • 비즈니스 프로세스에서 발생한 이벤트

  • 과거형으로 작성한다.

• User/Actor: (노란색 스티커)

  • 커맨드를 실행하는 사람

  • 혹은 보는 사람

• Business Process: (보라색 스티커)

  • 비즈니스 룰이나 로직을 통해서 커맨드를 처리한다.

  • 하나 혹은 여러개의 도메인 이벤트를 생성한다.

• Command: (하늘색 스티커)

  • 사용자에 의해서 실행된 커맨드

  • 집계된 뷰로 도메인 이벤트의 생성 결과등으로 보여지는 영역

• Aggregate: (주황색 스티커)

  • 도메인 객체의 모임

  • 하나의 단위로 처리되어야 하는 객체모임이다.

• External System: (옅은 붉은색 스티커)

  • 결제 게이트웨이, 배송 회사 등과 같이 외부 시스템

  • 서드파티 서비스 제공자등이 될수 있다.

• View/Read Model: (녹색 스티커)

  • 뷰로 사용자와 상호작용하여 시스템에서 작업을 수행한다.

• Question Marks / Risks: (붉은색 스티커)

  • 명확하지 않은 토픽 혹은 질문등 기술

  • 다음 회의때 해결해야하는 것들 등

진행방법

Step-1: Domain Event를 수집한다. (큰 그림을 그림)

• 참여자들은 오랜지색 포스트잇을 사용하여 작성한다.

• 특정 이벤트들을 포스트잇에 작성한다.

• 특정 이벤트는 비즈니스에서 발생한 기술적 사한들을 작성한다.

• 반드시 과거형으로 작성한다.

• 첫 라운드는 순수한 브레인스토밍이다.

• 존재하는 도메인 이벤트가 무엇인지에 대해서 브레인스토밍으로 뽑아내기만 한다. 평가하지 않는다.

• 발생되는 순서대로 포스트잇을 붙인다.

Step-2: Domain Event 정제 (큰 그림)

• Domain Event 를 검토한다.

• 각 이벤트가 의미하는 것을 질문하고 설명하는 시간을 가진다.

• 의미상으로 올바른지 검토한다.

• 또한 시간순으로 올바르게 나열되어 잇는지 살펴본다.

• 동일한 이벤트들, 혹은 의미상으로 유사한 이벤트들을 그룹화하고, 다른 부분은 명확히 다름을 확실히 한다.

Step-3: Track causes (Process Modeling)

• 원인에 대해서 연구하기

• 특정 이벤트가 어디서 발생했는가?

• 4가지 주요 원인에 대해서 알아보기

  • 사용자 작업인가? (명령, 사용자/액터, 모델보기/읽기),

  • 외부 시스템으로 인한 작업인가?

  • 다른 도메인 이벤트로 발생한 작업인가?

  • 이벤트의 트리거에 대해서 물어보기

Step-4: Re-Sorting & result (소프트웨어 모델링)

• 이제 타임라인으로 부터 포스트잇 제거하고, aggregator로 묶어주기

• 이들을 새로운 연관 만들어주기

  • 어떤 사용자가 어떠한 커맨드를 실행하는가?

  • 어떤 커맨드가 어떤 어그리게이트 혹은 외부 시스템에 영향을 미치고, 어떤 변경을 만들어 내는가?

  • 커맨드 처리 중에 어떤 집계 또는 외부 시스템이 어떤 이벤트를 트리거 하는가?

  • 어떤 이벤트가 어떤 정책을 트리거 하는가?

  • 어떤 이벤트가 어떤 사용사례에 대한 어떤 읽기 모델을 생성하는가?

  • 어떤 정책이 어떤 새로운 명령을 호출하는가?

우리가 만들어야할 시스템 요구사항

1. OpenApi 스펙은 프로젝트단위로 작성할 수 있다

2. OpenApi 스펙을 업로드/다운로드 할 수 있다.

3. OpenApi 스펙을 생성/조회/수정/삭제 할 수 있다.

4. OpenApi 스펙 목록을 볼 수 있다.

5. OpenApi 스펙 검사를 수행할 수 있다.

6. OpenApi 스펙은 다음과 같은 저장소에 저장할 수 있다.

7. S3

8. GitHub

9. 서버내 파일시스템

10. OpenApi 스펙을 이용할때에는 액세스키/시크릿 키를 통해서만 사용할 수 있다.

11. 자체 버져닝을 할 수 있다.