이벤트 스토밍
이벤트 스토밍은 도메인 이벤트를 찾는 활동으로 시작을 했습니다. 도메인 이벤트를 동작하게 하는 command를 찾는 활동에 대해 알아보겠습니다.
커맨드
command는 도메인 이벤트를 발생시키는, 즉 도메인 이벤트를 동작하게 하는 명령입니다. 이 command의 이름은 change account, request shipment와 같이 명령어의 형태로 작성을 합니다. 찾은 command의 이름은 파란색 스티커에 작성을 해서 이 command과 연관된 도메인 이벤트의 왼쪽에 붙입니다.
account changed라는 도메인 이벤트를 동작하게 하는 만드는 command으로 change account를 적어서 account changed 스티커의 왼쪽에 붙입니다. 이 방법으로 account registered, purchase requested 그리고 purchase confirmed까지의 도메인 이벤트를 발생시키는 command를 찾아 그 이름을 파란색 스티커에 작성을 해서 화면과 같이 각각 관계되는 도메인 이벤트를 찾아 붙였던 주황색 스티커 옆에 붙여보았습니다.
그러나 모든 도메인 이벤트가 command이 있는 것은 아닙니다. payment approved와 payment declined의 도메인 이벤트는 신용카드 결제 시스템으로부터 결제가 승인되거나 거부되었을 때 발생하는 이벤트들로 별도 command 없이 외부 시스템으로부터의 응답으로 인해 실행되는 도메인 이벤트입니다. 또한 일 단위, 주 단위, 월 단위로 정해진 시간에 동작하는 경우나 제한된 시간에 도달하면 발생하는 도메인 이벤트의 경우에도 command가 없을 수 있습니다.
예를 들어 매월 말일에 당월 매출액을 계산하는 도메인 이벤트의 경우 화면과 같이 도메인 이벤트 이름 옆에 표시를 통해 이 이벤트가 매월 말일 동작한다는 것을 나타낼 수 있습니다. product registered 이벤트를 발생시키는 register product, product updated 이벤트를 발생시키는 update product, product shipped 이벤트를 발생시키는 request shipment command가 있습니다.
그 밖에 다른 도메인 이벤트에 대해서도 계속해서 command를 찾아 화면과 같이 해당 도메인 이벤트 스티커의 왼쪽에 붙여나갑니다. 모든 이벤트에 대해 command를 찾아 붙이게 되면 command과 도메인 이벤트가 짝을 이루어 붙여지게 됩니다. 이렇게 도출된 command는 사용자, 즉 사람 또는 사람이 아닌 특정한 역할을 통해 command가 동작하게 됩니다.
사용자 또는 역할을 찾을 때에는 해당 command를 동작하게 하는 구체적인 사용자나 역할을 찾는 것이 중요합니다. 이렇게 찾은 사용자 또는 역할은 노란색의 작은 스티커에 이름을 적어 command 스티커의 왼쪽 아래에 약간 겹치게 붙이게 됩니다. 이 사용자 역할 스티커를 해당 command에 겹치게 붙이는 것은 이 사용자 또는 역할이 command를 동작하게 한다는 것을 명시적으로 표현합니다.
이렇게 command와 사용자를 찾아 붙이는 과정을 진행합니다. 이전에 생각하지 못했던 도메인 이벤트를 떠올릴 수도 있습니다. 이때는 생각이 떠오르는 즉시 도메인 이벤트를 주황색 스티커에 작성해서 붙이면 됩니다. 이런 것들이 쌓이고 반복된다는 것은 참석자들이 이 이벤트 스토밍을 통해 도메인에 대해 더 깊이 탐구하고 이해하는 것을 의미합니다.또, 서로 간의 눈높이, 이해의 깊이를 맞춰가고 있다는 것을 의미합니다. 이것이 워크숍을 통해 얻을 수 있는 중요한 이점 중에 하나이기도 합니다.
사용자
register account command를 동작하게 하는 사용자는 아직 회원이 되기 전의 상태로 명확하게 정의한다면 게스트로 정의할 수 있습니다. change account와 remove account는 이미 회원가입이 된 이후에 수행하는 것입니다. 이 command를 동작하게 하는 사용자, 역할은 멤버로 정의를 합니다.
request purchase, 즉 구매를 요청하는 사람은 구매자, 그러니까 구매를 하는 사람이니까 buyer로 정의를 하고,
request payment command의 경우는 결제를 하는 사람, 즉 payer로 정의할 수 있습니다. 그리고 구매한 제품을 받을 배송지 정보를 입력하라는 enter shipping info command는 멤버이기도 하고 buyer이기도 하고 또는 payer이기도 합니다.
구매한 제품을 받는 사람, 즉 수취자를 의미하는 receiver로 정의할 수가 있습니다. 이렇게 구체적인 사용자나 역할을 찾는다는 것을 생각합니다. 모든 command에 대해 사용자, 역할을 찾는 것을 계속 진행합니다. register product, set product details, update product command들은 판매할 제품을 등록하고 상세 정보를 입력하는 사람으로 판매자, 즉 seller로 정의할 수 있습니다.
도메인 이벤트와 이 이벤트를 발생시키는 command 그리고 또 이 command를 발생시키는 사용자나 역할을 찾는 활동을 진행해보았습니다. 지금까지의 활동을 통해 이 워크숍에 참여한 사람들은 이 쇼핑몰 서비스를 사용하는 사용자나 역할 그리고 이 사용자나 역할이 어떤 command를 발생시키고 또 이에 따라 시스템이 어떻게 동작하는지에 대해 알 수 있게 됩니다.
지금까지 활동은 많은 설계자와 개발자들이 관심을 갖는 데이터보다는 도메인과 비즈니스의 흐름에 집중해서 진행이 되었습니다. 이벤트 스토밍의 도메인 이벤트, 실행 프로세스나 외부 연계 시스템 그리고 도메인 이벤트를 동작하게 하는 command, 또 이 command를 동작하게 하는 사용자나 역할을 찾는 활동을 통합니다. 만들어야 할 소프트웨어에 대한 이런 활동은 도메인에 대한 지식을 가시화함으로써 전체 쇼핑몰 서비스의 큰 그림을 그릴 수 있습니다.
또한 어떤 사용자가 어떤 command를 통해 도메인 이벤트를 발생시키는지를 찾아보면서 다양한 사용자들의 시작부터 끝까지의 역할에 따른 큰 흐름을 찾아낼 수 있습니다. 쇼핑몰에 회원으로 가입한 후 회원이 되면 이 회원의 상품 구매를 위한 전체 프로세스, 즉 상품을 구매하고 결제를 해서 최종 배송된 상품에 대해 수령을 확인하는 것까지 프로세스를 찾아낼 수 있게 됩니다.
또한 이 쇼핑몰 서비스의 또 하나의 사용자인 상품 판매자는 쇼핑몰에 상품과 상품의 상세정보를 등록하고, 구매가 승인된 상품을 구매자에게 배송하는 것까지의 프로세스를 찾을 수 있습니다. 또한 이전에 찾았던 자주색 스티커, 즉 핫스팟을 보면서 큰 그림에 있어서 또는 특정 프로세스를 수행하는 데 있어서 어떤 문제점이 있는 지 알 수 있습니다.
추가로 더 확인해야 할 것들이 있는지와 같은 프로젝트에서 문제가 될 만한 것들을 한눈에 볼 수도 있습니다. 팀 전체는 이런 중요한 문제점들에 대해서 모두 인지를 하고 공감대를 가질 수 있습니다. 소프트웨어는 내부의 여러 기능이 연계를 통해 동작하게 됩니다. 새로운 기능의 추가나 개선이 계속해서 진행됨에 따라 점점 더 복잡해지는 문제가 발생될 수 있습니다.
따라서 크고 복잡한 도메인을 여러 개의 서브도메인으로 나누어야 합니다. 주요 사용자들의 핵심 프로세스를 분석해서 전체 쇼핑몰 도메인을 여러 개의 서브도메인으로 나눠볼 수 있습니다. 쇼핑몰 도메인은 2개의 핵심 서브도메인과 3개의 지원 서브도메인 그리고 2개의 일반 서브도메인으로 서브도메인을 식별했습니다.
서브도메인은 마커펜으로 표시하는데 화면과 같이 점선으로 표시를 합니다. 상품 등록과 상품 구매에 대한 영역을 핵심 서브도메인으로 선정합니다. 그 이유는 상품 등록은 추후 많은 판매자를 유치하기 위해 판매 상품의 등록 방법이 쉽고 빠르게 편리해야 합니다. 다른 쇼핑몰과 차별화해서 구현합니다. 구매 또한 구매를 유도하기 위한 상품 추천 기능이 지속적으로 개선되어야 하므로 이 두 가지를 쇼핑몰 서비스의 핵심 서브도메인으로 선정하였습니다.
그리고 회원가입 시 입력한 정보를 상품 추천에 활용하기 위해 회원가입을 지원 서브도메인으로 선정하였습니다. 반품과 구매후기 또한 중요하므로 지원 서브도메인으로 선정하였습니다. 그 외 배송과 관련된 기능은 외부의 배송업체를 통해 진행되는 업무로 쇼핑몰 시스템에서는 배송업체의 배송현황 화면을 링크를 통해 제공할 계획입니다. 때문에 일반 서브도메인으로 선정하였습니다.
지금까지 이벤트 스토밍 기법을 통해 도메인 이벤트를 찾앗습니다. 이 도메인 이벤트를 동작시키는 command, 이 command을 동작하게 하는 사용자를 찾아보는 활동을 진행하였습니다. 이를 통해 전체 비즈니스 도메인의 큰 그림을 그려보고 또 각 사용자별 주요 프로세스를 찾을 수 있었습니다. 이 크고 복잡한 쇼핑몰 서비스를 중요도에 따라 2개의 핵심 서브도메인, 3개의 지원 서브도메인 그리고 2개의 일반 서브도메인으로 분할을 할 수 있었습니다.
'SW > 마이크로서비스' 카테고리의 다른 글
마이크로서비스 : 내부 설계를 위한 전술적 설계 및 주요 개념 : 정의, 개요, 설명 (0) | 2020.05.22 |
---|---|
마이크로서비스 : 쇼핑몰 서비스 : 세번째 설계 이야기 (0) | 2020.05.15 |
마이크로서비스 : 쇼핑몰 서비스 : 첫번째 설계 이야기 (0) | 2020.05.14 |
마이크로서비스 : 전략적 설계의 정의, 이벤트 스토밍 : 개념, 정의, 개요 (0) | 2020.05.13 |
마이크로서비스 : 전술적 설계 : 정의, 개념, 개요 (0) | 2020.05.13 |