2.3 이벤트 스토밍: 도메인을 해석해 모델 만들기 #1539
Description
2.3 이벤트 스토밍: 도메인을 해석해 모델 만들기
2.3.1 이벤트 스토밍을 통한 모델링
이벤트 스토밍은 도메인 주도 설계의 공통된 도메인 모델링을 위한 워크숍입니다.
이벤트 스토밍의 큰 장점 중 하나는 참가자들 사이에 ‘유비쿼터스 언어’를 구축할 수 있다는 점입니다.
이벤트 스토밍 개요
- 빅 픽처
- 비즈니스 프로세스 모델링
- 소프트웨어 시스템 모델링
진행 유형과 각각의 준비
- 온라인으로 진행
- 오프라인으로 실시
구체적인 유스케이스의 설정
워크샵에서 유스케이스가 구체화되지 않으면 참가자들이 지치고, 원하는 성과를 단기간에 얻지 못하는 경우가 많았습니다.
결국 이벤트 스토밍에 대한 기대치와 결과 사이의 괴리로 인해 그 효과가 반감되는 결과를 초래할 수 있습니다.
그래서 처음에 이벤트 스토밍을 진행할 때는 제한된 소규모의 유스케이스를 설정하는 것이 좋습니다.
그래야 참가자들이 집중해서 참여할 수 있고, 이벤트 스토밍의 효과를 제대로 확인할 수 있기 때문입니다.
2.3.2 빅 픽처
이 단계에서는 프로젝트나 도메인 전체를 조망하기 위해 관련 이벤트들을 모두 기록하고 시간순으로 정렬합니다.
이러한 과정에서 누락된 이벤트를 발견하거나 새로운 이벤트를 추가할 수 있으며, 이벤트 외에도 논의가 필요한 중요한 주제를 추가로 도출할 수도 있습니다.
이벤트 쓰기
여기서 한 가지 중요한 것은 아무리 작은 이벤트라도 중요한 통찰력을 제공할 수 있으니, 이 단계에서는 아이디어를 평가해서는 안 된다는 점입니다.
참가자들은 도메인과 관련된 각각의 이벤트를 간결하게 과거형으로 표현합니다.
예를 들면 호스팅 서비스 신청 과정에서는 ‘신청함’, ‘서버를 준비함’ 등의 이벤트가 있습니다.
이벤트는 타임스탬프가 찍힌 과거형
나중에 작성된 내용이 이벤트로 적절한지 정하기 위해서는 작성된 내용에 타임스탬프가 찍힐 수 있을지 여부가 하나의 판단 기준이 됩니다.
예를 들어 ‘서버 다운’에는 ‘2023년 7월 1일 오후 3시에 서버가 다운되었다’라고 타임스탬프를 붙일 수 있습니다.
이벤트를 시간순으로 정렬한다
모든 이벤트를 발생한 순서대로 정렬합니다.
이 과정을 통해 도메인의 흐름과 이벤트 간의 관계가 더욱 명확해집니다.
각각의 이벤트가 언제 일어났는지를 시각적으로 이해하게 되면 누락된 이벤트를 찾아내기도 쉽습니다.
해피 패스와 핫 스팟으로 중심을 잡는다
해피 패스는 오류나 문제없이 성공적으로 진행하기 위한 표준 시나리오를 말합니다.
어느 정도의 이탈은 허용하되, 본질적으로는 해피 패스를 중심으로 프로세스를 진행해야 합니다.
핫 스팟은 미결정 사항으로 볼 수 있습니다.
토론이 진행되다 보면 당장 결정할 수 없는 중요한 사안이나 도메인에 예상치 못한 중요한 업무 지식이 튀어나올 수 있습니다.
이런 정보들은 중요한 정보이면서도 성공적인 표준 시나리오에서 옆길로 새게 만드는 문제들입니다.
이럴 때 핫 스팟이라고 정보를 기록합니다.
2.3.3 비즈니스 프로세스 모델링
비즈니스 프로세스 모델링은 빅 픽처에서 파악한 이벤트를 사용해 업무 흐름을 더 세부적으로 파악하는 단계입니다.
이 단계의 주요 목적은 서로 다른 이벤트를 연결하는 방법을 자세히 검토하는 것입니다.
이벤트와 이벤트를 연결한다
이벤트는 자동으로 이어지는 것이 아니라 특정 조건이나 트리거에 의해서만 다음 이벤트로 연결됩니다.
명령
이벤트를 연결하려면 먼저 이벤트를 유발하는 핵심 요소인 명령을 추가해야 합니다.
각 이벤트는 그 자체로 발생하는 것이 아니라 시스템이나 프로세스에 대한 구체적인 지시나 동작을 나타내는 명령에 의해 발생합니다.
애그리게이트
명령과 이벤트는 직접적으로 연관되어 있지 않으며, 명령을 전달하는 매개체를 통해 이벤트가 발생합니다.
애그리게이트는 명령을 전달하는 매개체로, 실제 이벤트를 발생시키는 역할을 수행합니다.
외부 시스템
업무 프로세스에 직접적인 영향을 미치는 요소에는 우리가 직접 통제할 수 없는 외부 시스템도 있습니다.
예를 들면 다른 부서에서 관리하는 시스템과의 연동이나 타사의 결제 시스템 등이 있습니다.
이런 시스템들도 명령을 받고 이벤트를 발생하는 것으로 간주할 수 있기 때문에, 명령과 이벤트를 연계하는 매개체에 해당합니다.
정책
정책은 이벤트와 명령을 연결하는 중요한 요소로, 특정 이벤트가 발생했을 때 명령이 자동으로 실행되게 사전에 정해 놓은 규칙을 말합니다.
액터를 매개로 이벤트 연결하기
액터와 리드 모델
액터는 사용자, 시스템 등 다양한 형태로 존재하며 리드 모델을 참조해 얻은 정보를 바탕으로 명령을 내립니다.
또한 비즈니스 프로세스의 다음 단계를 결정하고 적절한 조치를 취하는 역할을 합니다.
리드 모델은 액터가 명령을 내리는 데 참조하기 위한 정보이며, 데이터 모델이나 메일, 대시보드 화면 등 다양한 형태로 시스템에 존재합니다.
구체적인 액터의 예
호스팅 서비스의 경우 사용자가 서비스를 신청했을 때 서버 준비가 완료되면 제어판의 서버 실행 상태가 바뀝니다.
이 ‘서버 실행 상태’는 액터가 결정을 하는데 참조가 되는 리드 모델의 일부입니다.
사용자(액터)는 실행 상태를 확인하고 ‘초기 설정하기’라는 명령을 내립니다.
이 행동은 리드 모델에서 얻은 ‘서버 실행 상태’ 정보를 기반으로 하며, 사용자가 취할 수 있는 다음 단계를 명확히 합니다.
조건 분기
정책에 의한 조건 분기
정책은 애그리게이트의 내부 상태가 아닌 외부 상황에 대한 조건에 주목합니다.
예를 들어 서버의 제어판이 이미 생성되어 있는지와 같은 조건에 따라 사용자 인터페이스용 데이터 생성과 같은 특정 프로세스를 작동할지의 여부가 결정됩니다.
애그리게이트에 의한 조건 분기
애그리게이트에 의한 조건 분기에서는 애그리게이트의 내부 상태에 따라 어떠한 이벤트를 발생시킬지가 결정됩니다.
예를 들면 서버의 상태가 유지보수 모드인지, 정상 모드인지에 따라 시스템의 응답이 달라집니다.
액터에 의한 조건 분기
액터는 리드 모델의 정보를 바탕으로 판단하고 명령을 내린다는 점에서 액터 자체가 조건 분기를 담당합니다.
마무리를 향해
이 단계에서는 지금까지 파악된 해피 패스의 세부 사항을 구체화하고, 시스템의 견고성을 검토합니다.
또한 애그리게이트의 역할과 경계를 최종 점검하고 전체 설계를 완성하는 것을 목표로 합니다.
새드 패스 작성하기
이상적인 해피 패스가 작성되면, 예상치 못한 오류가 발생했을 때를 대비하여 최악의 패스를 작성합니다.
이러한 패스를 편의상 새드 패스(sad path)나 언해피 패스(unhappy path) 등으로 부릅니다.
새드 패스를 통해 시스템이 예기치 않은 오류나 예외 상황에 어떻게 대처해야 하는지 이해하고, 적절한 오류 핸들링과 예외 처리를 위한 전략을 수립할 수 있습니다.
애그리게이트로 명명하기
모든 이벤트를 규칙에 따라 연결했다면 이제 애그리게이트의 이름을 지정할 차례입니다.
하지만 여기서 정하는 이름은 임시적인 것으로 몇 번의 검토를 거쳐서 최종적인 이름을 확정할 것입니다.
애그리게이트 이름을 정할 때 해당 명령의 목적어나 이벤트의 주어나 목적어가 좋은 단서가 됩니다.
유비쿼터스 언어의 형성을 촉진
다른 개념을 동일시하는 경우는 다른 개념을 같은 말로 표현하는 것으로, 비즈니스적으로는 문제가 없지만 시스템으로 표현할 때는 혼란이 발생할 수 있습니다.
참가자 모두가 합의하여 명확히 의미를 구분해 사용하면 좋습니다.
2.3.4 소프트웨어 시스템 모델링
소프트웨어 시스템 모델링 단계에서는 비즈니스 프로세스 모델링에서 나온 특정한 요소를 더욱 상세하게 분석하여 소프트웨어 시스템에 녹여냅니다.
참여자 변경
바쁜 도메인 전문가를 모든 단계에 참여시키기보다는 꼭 필요한 단계에만 참여할 수 있게 하는 것이 바람직합니다.
물론 도메인 전문가가 자발적이면서 지속적으로 참여하려 한다면 함께하는 것도 좋습니다.
도메인 전문가의 통찰력은 애그리게이트를 정의하는 데 큰 도움이 될 수 있습니다.
애그리게이트의 정의와 심층 분석
팀 내 논의를 통해 애그리게이트의 정의가 끝나면 애그리게이트에 전송할 명령과 발생시킬 이벤트를 수집해야 하며, 이것이 곧 애그리게이트를 구현하기 위한 설계서가 됩니다.
객체지향 프로그래밍으로 비유해 설명하면 애그리게이트는 클래스를 나타냅니다.
그 클래스에서 사용되는 메서드나 인수는 명령을 수행하는 역할을 하며, 그 결과는 이벤트가 됩니다.
남겨야 할 다이어그램에 대하여
두 가지의 다이어그램을 모두 채택할 때 우려되는 점은 서로 연관된 다이어그램을 일관성 있게 유지보수하는 것이 어렵다는 점입니다.
만약 하나의 다이어그램만 남겨야 한다면 필자는 비즈니스 프로세스 모델링 다이어그램을 남기는 쪽을 권합니다.
컨텍스트의 발견
여기서 말하는 컨텍스트는 도메인 주도 설계의 개념 중 하나인 경계 컨텍스트를 의미합니다.
시스템이나 비즈니스 프로세스의 특정 부분이나 언어의 범위를 정의하는 그룹으로, 전체 시스템에서 특정 도메인 모델이 적용된 범위를 나타냅니다.
2.3.5 피드백 루프
도메인 전문가와 팀이 피드백을 주고받으면서 새로운 방법을 수립하기 위해 노력해야 합니다.
이렇게 지속적인 협의와 조정이 이루어지는 피드백 루프는 더 정교한 모델을 만들기 위한 필수 요소입니다.