도메인 지식 탐구를 위반 이벤트 스토밍(Event Storming) 요약

728x90

KCD 2020에서 Jason이 발표한 영상을 보고 요약한 내용입니다. (17분이 조금 안되는 짧은 강의이니 요약 글을 보는 것 보다는 직접 영상을 시청하는 것을 추천한다 👍)

대상

  • 이벤트 스토밍이 소프트웨어 개발 프로세스의 일부로 매력적인 아이디어라고 생각하는 분
  • 도메인 주도 설계(DDD)에 대한 기본적인 이해와 바운디드 컨텍스트애그리게잇, 도메인 이벤트가 무엇인지 아는 분
  • 지금은 무엇인지 모르겠으나 나중을 위해 미리 듣는 분

DDD의 내용을 잘 모르거나 혹은 개념을 잘 모른다면, 최범균님의 책 DDD START! 읽고 요약한 내용을 참고해보면 좋을 것 같다. 참고로 요약한 나도 DDD는 아직도 잘 모르겠다. 🥲

들어가기에 앞서서...

이벤트 스토밍은 개발자만을 위한(=DDD를 위한..) 것이 아닌 여러가지 문제 식별과 해결에 좋은 도구이며 다른 용도로도 얼마든지 사용될 수 있다.

Domain-Driven-Design

  • 실제 코드로 구현 가능한 현실성 있는 도메인 모델 분석과 그것을 추상화하는 설계
  • 도메인 모델의 적용 범위를 구현까지 확장하여 도메인 지식을 구현 코드에 반영한다.

도메인이란...?

소프트웨어로 해결하고자하는 문제 영역이다. (ex. e-commerce의 경우 제품 판매)

DDD를 도입하는데에는 많은 어려움이 있다.
ex) 바운디드 컨텍스트를 나누는 기준은 무엇인가요?, 애그리게잇은 어떻게 도출할 수 있나요?, 현재 업무에 DDD를 도입하려면 어떻게 시작해야 하나요? 등

DDD가 성공하기 위한 전제 조건

  • 앞서 말했지만 DDD는 개발자만을 위한 것이 아니다.
  • 이해관계자(stakeholder)의 스폰서십이 적극적으로 필요하다.

DDD 도입이 어려운 이유는... ?

  • 특정 분야에서만 전문가인 도메인 전문가
  • 도메인에 거의, 혹은 전혀 관심이 없는 동료 개발자
  • 모든 사람이 동일한 개념에 대해 다른 용어를 사용하거나, 다른 개념에 대해 동일한 용어를 사용한다.
  • 하나의 기능을 개발하기 위해 동료 A에게도 물어보고 동료 B에게도 물어봐야 한다.
    • 복잡한 문제를 해결하기 위해 필요한 지식을 수집하는 것이 쉽지않기 때문이다.

소개

  • Alberto Brandolini가 제안한 워크숍으로 복잡한 비즈니스 도메인을 빠르게 탐색하고 학습할 수 있는 방법이다.
  • 도메인 전문가와 개발자를 학습 과정에 참여시키기 위한 빠른 설계
  • 코드를 없애고 모든 사람을 동일한 수준으로 만드는 시각적 접근 방법

(워크숍) 준비물

  • 큰 회의실, 커다란 종이, 수많은 포스트잇과 마커펜
  • 실제 문제 해결에 관련된 모든 사람(질문이 있는 사람, 답을 가진 사람)
  • 퍼실리테이터(회의나 교육의 진행을 원활하게 이뤄지게 돕는 역할)

진행 방법

  • 벽에 커다란 종이를 붙여 놓고 그 위에 포스트잇을 붙여 나간다.
  • 모든 사람의 생각을 허용하고 존중한다.
  • 비즈니스 프로세스를 이해하는 데에 초점을 맞춘다.

이벤트 스토밍의 가치는 단순히 포스트잇을 벽에 붙이는 것이 아니라, 커뮤니케이션이다.

이벤트 스토밍의 핵심 원칙모든 참가자의 참여를 극대화하는 것이며 포스트잇을 사용하여 모든 사람이 적극적으로 참여할 수 있도록 한다.

왜 포스트잇인가?

  • 가장 간단한 표기법을 사용하면 회의실에 있는 모든 사람이 적극적으로 참여할 수 있다.
  • 떼어 내고 붙이기가 쉽기 때문에 이동이 가능하며, 틀린 경우에도 뗄 수 있어 부담을 줄일 수 있다.
  • 구현 코드보다 포스트잇을 변경하는 것이 훨씬 저렴하다.

(주의⚠️ 개발자가 아닌 사람에게 UML 다이어그램을 배우도록 강요해서는 안 된다. 이벤트 스토밍의 핵심 원칙은 모든 참가자의 참여를 극대화하는 것이다.)

1단계: 혼란스러운 탐험

  • 각자가 알고 있는 도메인 이벤트를 작성하도록 요청한다.
  • 각자가 작성한 이벤트는 볼 수 있지만, 토론을 시작하지 말고 자신이 옳다고 생각하는 방식으로 기록한다.

(예시는 넥스트스텝 플랫폼의 수강신청 과정을 예로 든다)

도메인 이벤트 - 주황색

  • 도메인 전문가가 관심이 있는 어떤 사건
  • 이벤트 이름은 과거에 일어났던 일을 표현하기 때문에 과거 시제를 사용한다.
  • 이벤트가 발생한다는 것은 상태가 변경되었다는 것을 의미한다.

보통 '~할 때', '~가 발생하면', '만약 ~하면'과 같은 요구 사항이 해당한다.

image

2단계: 타임라인 적용

  • 모든 도메인 이벤트를 올바른 타임라인으로 정렬하고 실제로 중복되는 이벤트를 제거한다.
  • 시간은 왼쪽에서 오른쪽으로 흐르고, 위에서 아래로 평행한 시간을 표현할 수 있다.
    (실제로 중복이라는 표현을 쓴 이유는 동일한 용어지만 다른 개념일 수도 있기 때문이다)

image

핫 스폿 - 자주색

  • 2단계에서 발생한 갈등을 시각화하고 캡처하는 데 사용한다.
  • 당장 토론하지 않는다. 나중에 문제가 해결되면 제거한다.

image

액터와 시스템 - 노란색과 분홍색

  • 단순한 '사용자' 또는 '고객'보다 구체적인 페르소나를 설정한다. (ex. 강사, 교육생, 수강생 등...)
  • 외부 시스템부터 일부 레거시 및 마이크로서비스에 이르기까지 책임을 전가할 수 있는 모든 것

image

바운디드 컨텍스트

  • 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있다.
  • 명백한 언어 불일치는 종종 동일한 프로세스 내에서 여러 개의 바운디드 컨텍스트를 나타내는 지표이다.

바운디드 컨텍스트내에서 정의되는 언어를 유비쿼터스 언어라고 부른다. 똑같은 강의라고해도 어떤 컨텍스트에 있냐에 따라 강의 컨텐츠를 의미할 수도 있고 미션을 의미할 수도 있고, 상품을 의미할 수도 있다. 팀에서 역할이 무엇인든, 프로젝트에 참여하고 있는 사람들이 유비쿼터스 언어를 사용하도록 묶을 수 있는 장치는 용어 사전이며, 유비쿼터스 언어가 가장 지속적으로 유지되고 유일하게 보장되는 영역은 개발자의 코드지만 유비쿼터스 언어는 개발자의 것만이 아님을 명심해야한다.

바운디드 컨텍스트까지 나눈 후에는, 실제 프로세스가 어떻게 이루어지는지 찾아봐야 할 때다.

커맨드 또는 액션 - 파란색

  • 시스템에서 일어나는 일
  • 도메인 이벤트가 발생하는 원인

리드 모델 또는 정보 - 초록색

  • 결정을 내리는 데 필요한 정보

image

정책 - 연보라색

  • 주로 '~할 때마다'라는 단어로 시작한다.
  • 도메인 이벤트커맨드 사이에 위치한다.

주황색인 도메인 이벤트와 파랑색인 커맨드 사이에 위치하고 단순한 조건부터 복잡한 정책까지 모두 될 수 있다.

에그리게잇 또는 비즈니스 규칙 - 연노란색

  • 시스템이 기대하는 책임을 수행하며 일관성을 유지하는 단위
  • 일관성은 항상 참이어야 하는 속성을 유지함으로써 달성된다.

애그리게잇: 실제로 주어진 클래스들의 계약을 정의하는 방법이며 내부의 구현은 자유롭게할 수 있다. 일종의 캡슐이라고 볼 수 있다.
(개발자가 아닌 사람에게 에그리게잇이라는 용어를 강요해서는 안 된다. '이벤트 규칙'과 같은 말로 바꿔쓸 수 있다.)

image
수강신청과 결제 컨텍스트는 강의, 결제시도, 결제 3개의 애그리게잇으로 이루어진 것을 볼 수 있다.

Event Storming이 끝나고 난 뒤

image

이벤트 스토밍이 익숙치 않을 때에는, 일관된 색상규칙을 만드는 것을 추천한다. (test 코드 짜는 방식이 익숙하지 않을 때, Given, When, Then 구조를 지키는 것과 유사하다)

언택트 Event Storming

  • Miro, Mural
  • 누가 썻는지 알기 어렵다. -> 각자의 색상을 선택하여 포스트잇을 붙인 후 타임라인을 적용하고 주황색으로 변경한다.
  • 많은 사람들이 동시에 대화를 나누는 것이 어렵다. -> 음성 이외의 수단도 사용하고 추적한다.
  • 5분마다 번갈아가며 몹(mob) 모델링을 한다.
  • 노골적인 퍼실리테이터
  • 스탠딩 책상과 카메라

Event Storming을 통해서 우리가 얻을 수 있는 것

  • 모두가 서로에게서 배운다.
  • 모두가 서로 소통한다.
  • 자신의 관점에서 문제를 발견하면 누구나 말할 수 있다.
  • 모두가 문제를 해결하는 방법에 대한 자신의 아이디어를 제공한다.
  • 워크숍 후에는 모두가 같은 사실을 알게 된다.
728x90