이벤트 스토밍

 🐻
회사 프로젝트 설계 단계에서 이벤트 스토밍을 도입해보면서 느낀점과
이벤트 스토밍이 무엇인지 소개해보려 한다.

이벤트 스토밍은 도메인 주도 설계(DDD)를 가속화 시킬 수 있는 기법이다.

이벤트 중심으로 이해 관계자들이 모여 브레인 스토밍하는 워크샵을 뜻한다.

 

오프라인에서는 포스트잇으로 하지만, 온라인으로 miro나 whimsical 툴을 사용한다.

참여자

• 개발자
• 기획자
• 도메인 전문가(해당 기능을 사용하는 사람들)

아래 이미지들은 이벤트 스토밍의 결과물이다.

결과물을 먼저 살펴보고 각각 요소들을 알아보자.

이벤트 스토밍 1단계

토론을 시작 전 자신이 옳다고 생각하는 방식으로 각각 기록한다.

2시간 기준 100개 ~ 200개 정도 도출을 목표로 진행한다.

도메인 이벤트(주황색)

• 관심이 있는 어떤 사건이라는 의미를 가진다.
• ~할 때, ~가 발생하면, ~하면과 같은 요구사항을 가진다.
• 보통 과거 시제, 수동의 형태로 기록한다.
• 이벤트가 발생한다는 것은 상태가 변경되었음을 의미한다.

이벤트 스토밍 2단계

1단계에서 도출한 모든 도메인 이벤트를 타임라인으로 정렬한다.

실제로 중복되는 이벤트는 제거한다.

중복 제거 시 100% 중복인지 아닌지 충분히 토론 후 제거하도록 한다.

당장 해결하지 못할 토론 주제(자주색)

• 이러한 주제는 당장 토론하는 것이 아닌 나중에 토론하도록 한다.
• 나중에 해결되면 이 포스트잇은 제거한다.

커멘드, 액션(파란색)

• 시스템에서 일어나는 일을 적는다.
• 도메인 이벤트가 발생되는 원인을 담는다.

구체적인 사용자(노란색)와 시스템(자주색)

• 구체적인 사용자는 페르소나를 의미하며 모호하지 않고 구체적인 이름을 가진다.
• 시스템은 보통 개발자들이 결정하며 다음과 같은 유형으로 나뉜다.
  • 외부 시스템(솔루션) : ex) Iamport, PayPal, Kinesis CJ 등
  • 레거시 시스템 : 보통은 기존에 존재했던 프로젝트를 의미한다. ex) 발주어드민, 노드 어드민 등

리드 모델, 정보(초록색)

• 결정을 내리는데 필요한 정보를 가진다.

정책(연보라색)

• 도메인 이벤트와 커멘드 사이에 위치한다.
• “~할 때마다 고려해야하는 어떤 것" 이라고 생각하면 쉽다.

애그리게잇, 비즈니스 규칙

• 시스템이 기대하는 책임을 수행한다.
• 일관성은 항상 참이어야 하는 속성을 유지함으로써 달성한다.
• 애그리게잇이라는 용어를 도메인 전문가에게 강요해서는 안된다.
  • 가볍게 “위 요소들을 아우르는 말” 이라고 이해하면 쉽다.

결론

🤔
이벤트 스토밍의 이점이 대체 뭘까?

 

요구사항을 수립하고 개발을 하다보면 요구사항이 빈번하게 변경되는 일을 비일비재하다.

물론, 도메인 전문가가 생각하기에 더 필요하고 더 중요한 기능이라면 요구사항은 충분히 변경될 수 있다.

하지만, 기획자,개발자와 도메인 전문가 사이에 오해가 생겨 개발했던 걸 되돌리는 상황이 충분히 생길 수 있다.

 

이벤트 스토밍을 통해 기획, 설계 단계에서 모든 이해관계자가 모여 기획, 설계를 탄탄히 해놓으면 시행착오를 방지할 수 있고 나중에 요구사항이 변경되더라도 탄탄한 설계가 받쳐줌으로써 수정에 유연할 수 있다.

 

이벤트 스토밍을 해보면서 느낀점은 다음과 같다.

1. 어떠한 주제에 대해서 토론이 길어지면 끊는 역할을 하는 사회자가 있으면 더 원활했을 것 같다.
2. 도메인 전문가와 개발자,기획자 사이에 용어 정리가 되는 자리여서 회의간 원활하게 소통이 가능했다.
3. 외부 솔루션(도메인 전문가들이 사용하는 솔루션)에 사용되던 기능들을 이해할 수 있는 자리여서 어떤 기능이 필요한지 명확하게 알 수 있었다.

 

또한, 도메인 전문가와 기획자, 그리고 개발자들이 사용하는 용어는 조금씩 다를 수 있다.

그렇기 때문에 모두가 이해할 수 있는 용어로 통일하고 사전을 만들어 다음 미팅 때 헷갈리는 일을 방지할 수 있다.

모두가 이해할 수 있는 용어는 유비쿼터스 언어라고 하며, 다음 이미지는 용어 사전의 예시 이미지다.

GitHub - woowacourse/service-apply: 우아한테크코스 지원부터 최종 합격까지 모든 과정을 관리한다.

[2022-04-17 추가 사항]

‘DDD로 시작하는 마이크로서비스 개발’ 책을 읽고 내용을 보충하였다.

이벤트 스토밍 순서

1. 도메인 이벤트 찾기
   • 비즈니스의 어떤 상태를 생성, 변경, 삭제하는 요소
   • 시스템의 화면을 연상하지 말고 비즈니스가 흘러감에 따라 비즈니스를 구성하는 요소들의 상태가 어떻게 변경되는지 생각한다.
2. 외부 시스템/외부 프로세스 찾기
   • 화살표까지 추가하여 외부 시스템을 호출한다는 것을 표시한다.
   • 시스템 구현 범위에 있는 기능이 아니더라도 시스템의 기능 구현을 위해 연계가 필요한 시스템들은 모두 도출한다.
3. 커멘드 찾기
   • 하나의 커멘드에 의해 여러 개의 이벤트가 동시 또는 연속해서 발생할 수 있다.
   • 조건에 따라 하나의 커멘드에 여러 개의 다른 이벤트가 발생할 수 있다.
4. 핫스팟(당장 해결하지 못할 토론 주제) 찾기
5. 액터(사용자/역할) 찾기
   • 액터를 도출하면서 다음과 같이 문장을 만들어 식별한 커멘드와 이벤트를 검토해볼 수 있다.
     • 관리자가 창고를 등록하면 [창고등록됨]이라는 이벤트를 발생함으로써 시스템이 동작한다.
   • 만약 문장이 자연스럽지 않다면 자연스럽게 커맨드와 도메인 이벤트를 변경하거나 새로 도출해낸다.
6. 애그리거트 정의하기
7. 바운디드 컨텍스트 정의하기
   • 정책은 사실 여기서 결정이 된다.
   • 정책은 이벤트 뒤에 따라오는 반응적인 비즈니스 로직으로, 어딘가에 존재하는 커멘드를 동작하게 한다.
     • [도메인 이벤트]할 때에는 항상 [커멘드]한다.
8. 컨텍스트 맵(관계) 정의하기
   • 컨텍스트 관계를 작성할 때에는 호출 관계의 방향을 고려해야 한다.
   • 호출할 때 호출 방식(동기/비동기) 또한 작성하는 것이 좋다.
   • 호출 방식은 데이터의 일관성 측면과 컨텍스트의 가용성 측면을 고려해서 선택한다.
   • 컨텍스트 간에 일관된 데이터가 필요하면 동기 호출, 결과적 일관성으로 충분하다면 비동기 호출
   • 동기는 실선, 비동기는 점선으로 표시하자.

최종적으로 마이크로서비스로 정의하려면 추가로 다음과 같은 질문을 고려해서 판단할 수 있다.

• (비즈니스 측면) 비즈니스 프로세스를 수행하기 위한 하나의 맥락의 단위로 구분할 수 있는가?
• (데이터 관점) 마이크로서비스별로 분리된 데이터를 정의할 수 있는가?
• (운영 조직 측면) 하나의 팀이 독립적으로 운영 가능한 단위인가?
• (배포 측면) 독립적으로 배포 가능한 단위인가?
• (변경 영향도) 변경 시 영향을 받는 마이크로서비스가 존재하는가?
• (클라우드/MSA 도입 목적 측면) 도입을 통한 기대효과를 충분히 활용할 수 있는가?

이를 모두 만족한다면 바운디드 컨텍스트를 최종 마이크로서비스로 식별하고, 만족하지 못한다면 각 질문의 결과에 따라 바운디드 컨텍스트를 분리하거나 통합해서 마이크로서비스로 식별한다.

5번까지는 비즈니스 관점에서 이벤트 스토밍이 진행됐다면 6번부터는 설계 수준으로 진행된다.