이벤트 스토밍

이벤트 스토밍

이벤트 스토밍은 빠른 주기의 학습 과정에 도메인 전문가와 개발자 모두가 참여하는 신속한 설계 기술이다. 이는 명사나 데이터보다 비즈니스와 비즈니스 프로세스에 초점을 맞춘다.

• 매우 구체적인 접근법이다. 모두가 포스트잇과 펜을 갖고 학습 및 설계 세션에 기여해야 할 책임을 갖는다. 비즈니스 측 사람들과 개발자 모두가 함께 같은 곳에 서서 함께 학습한다. 모두 유비쿼터스 언어를 함께 만든다.
• 모두가 클래스나 데이터베이스가 아닌 이벤트와 비즈니스 프로세스에 집중한다
• 매우 시각적인 접근법이다. 코드를 제외시키고 모두를 설계 프로세스의 초반부터 참여하게 한다
• 가장 빠르고 가장 적은 비용으로 수행할 수 있다. 포스트잇에 무언가를 썼는데, 나중에 그 내용이 적절하지 못하다는 것을 알았다면, 그 포스트잇은 구겨서 던저버리자.
• 팀은 이해의 폭을 획기적으로 증진시킬 수 있다. 이는 주기적으로 항상일어난다.
• 모든 사람들이 무언가를 배운다.
• 모델과 모델을 이해하는 데 문제가 있다면, 이를 가능한 한 앞 단계에서 빠르게 인지할 수 있다.
• 설계 수준 모델링 모두에 이벤트 스토밍 사용이 가능하다
• 스토밍 세션을 하나로 제한할 필요는 없다.

스토밍 진행

1. 일련의 도메인 이벤트를 포스트잇에 적으면서 비즈니스 프로세스를 도출하라. 도메인 이벤트로 사용하는 색은 오렌지 색이다.
   1. 가장 먼저 도메인 이벤트를 만들면서 데이터와 데이터 구조가 아닌 비즈니스 프로세스에 최 우선적으로 초첨을 둔다.(10~15분 정도 진행한다)
   2. 포스트잇에 각 도메인 이름을 적어라. 이것은 꼭 과거형 동사여야 한다.
   3. 모델링 공간에 포스트잇을 시간 순서대로 붙인다. 왼쪽에서 오른쪽으로 가는 것이 이벤트 발새으이 순서다. 시간 순서에 대한 이해가 그다지 높지 않은 경우에는 모델 안에 그에 상응하는 도메인 이벤트를 따라야 한다.
   4. 비즈니스 프로세스에 따라 다른 도메인 이벤트와 동시에 발생하는 도메인 이벤트는 같은 시점에 발생하는 에빈트 하부에 위치 가능하다(평행 프로세싱 구조는 수직적 공간을 활용해 표현한다)
   5. 스토밍 세션을 진행하면서 기존 또는 신규 비즈니스 프로세스의 문제점을 찾아내자. 이 문제는 자주색 포스트잇에 그것이 외 문제인가를 명확하게 표시하자.
   6. 가끔 도메인 이벤트의 결과에서 실행할 프로세스를 도출해야 할 때도 있다. 이것은 한 단계로 구분할 수도 있고 여러 개의 복잡한 단계로 구분할 수도 있다.

1. 각 이벤트로 발생된후 연이어 발생하는 반응형 액션을 정의한다. 이 정책은 라일락 생상을 사용합니다.
   1. 하나의 이벤트에 수행될 policy는 멀티 액션이 존재 할 수 있습니다

1. 각 도메인 이벤트를 생성하는 명령을 정의합니다. 가끔 도메인 이벤트가 다른 시스템에서 발생한 사건의 결과일 수도 있는데 결과적으로 이들 이벤트들은 시스템에 영향을 줍니다. 주로 사용자 행위의 결과로 명령이 만들어 지는데 그 명령이 수행되면서 도메인 이벤트가 생성됩니다.
   1. 밝은 파란색 포스트잇에 그에 상응하는 각 도메인 이벤트를 생성 시키는 명령의 이름을 적습니다.
   2. 밝은 파란색의 명령 포스트잇을 그 명령이 만드는 도메인 옆에 붙입니다.
   3. 이들은 명령/이벤트 처럼 짝이 지어져야 합니다.
   4. 만약 액션을 수행하는 특정한 사용자 역할이 있고 이를 명시하는 것이 중요하다면 밝은 노란 포스트잇을 사용해 붙입니다.
   5. 이때도 2번 의 항목처럼 Policy가 생길 수 있습니다. 이 프로세스는 한 단계 또는 여러 개의 복잡한 단계일 수 있습니다. 이것은 2번 항목처럼 붙이거나 화살표를 사용해 연결할 수 있습니다.
   6. 중간에 새로운 도메인 이벤트가 떠오른다면 즉시 바로 표현합니다.
   7. 여러 개의 도메인 이벤트를 유발하는 명령을 오직 1개만 식별 한 경우도 있습니다. 이때 1개의 명령을 정의하고 이 명령이 만들어 내는 여러 도메인 이벤트들의 왼쪽에 위치 시킵니다.

1. Actor를 정의합니다. Actor는 커맨드를 발생시키는 주체(사람 또는 시스템)을 말합니다. Actor는 담당자 또는 시스템이 될 수 있으며 직관적으로 파악될 수 있는 Actor경우 표시하지 않아도 무방합니다.

1. 도메인 이벤트 결과를 생성해내는 명령을 엔터티/애그리게잇에 연관시킨다. 앤터티/애그리게잇은 명령이 실행된 후 도메인 이벤트의 결과가 저장되는 데이트 저장소이다.
   1. 비즈니스 측 사람들이 애그리게잇이라는 단어를 혼란스러워 한다면 다른 이름을 사용해야 한다. 그들은 보통 앤터티라는 이름은 이해할 수 있으면 그냥 데이터라 이야기 해도 문제는 없다. 중요한 점은 포스트잇을 통해 애그리게잇이 나타내는 개념에 대해 팀이 명확하게 의사소통할 수 있어야 한다.
   2. 애그리게잇은 옅은 노란색 포스트잇을 사용한다. 이것은 명확한 명사형태로 표현한다
   3. 애그리게인 포스트잇은 action과 domain의 뒷쪽또는 약간 윗쪽에 위치 시킨다. 이 애그리게잇 내에 이벤트들이 연관 있다는 것이 나타나야 한다. 또는 포스트잇들 사이에 놓아도 된다. 명확한 인지가 된다면 그것으로 충분하다.

1. Bounded context를 식별한다. BC가 식별 되었다면 각 Context를 매핑하여 표현합니다. 이때 BC간 정보 참조 릴레이션 설정 을 추가할 수도 있습니다.
   1. 서로 다른 비즈니스 측 사람들이 같은 용어에 대해 서로 다른 정의를 갖거나 개념이 중요하긴하나 핵심도메임의 일부가 아닌 경계를 식별합니다.
   2. 컨텍스트는 실선으로, 서브도메인은 점선으로 표시합니다.
   3. BC이름은 분홍색 스티커로 표시합니다.

Reference

• 도메인 주도 설계 핵심