Overview
이전 시간까지 MSA와 DDD에 대해 알아보았다.
이번 시간에는 마이크로서비스를 도출하기 위해 활용할 수 있는 이벤트스토밍에 대해 알아보겠다.
SW마에스트로에서 멘티로 활동하며 본 프로젝트를 MSA로 설계, 개발하였고 마이크로서비스를 도출할 때 이벤트스토밍을 적용해보았다!
이벤트스토밍을 진행하기 전 팀원 모두 참고자료의 유튜브 영상을 시청하여 이벤트스토밍을 공부하고 이를 본 프로젝트에 적용하였다. 이 과정에서 MSAEZ 이벤트스토밍 협업 사이트를 활용하였다.
Event Storming
도메인 전문가(고객)은 IT용어를 알지 못한다. 개발자는 반대로 도메인 전문가의 언어를 이해하지 못한다. 이로인해 걸림돌 및 이슈가 발생하기 마련이다.
프로젝트 이해관계자들이 하나의 장소에서 내용을 공유한다면 DDD를 효과적으로 가져갈 수 있다.
이벤트 스토밍은 이벤트를 중심으로 이해관계자(도메인 전문가, 개발자, 테스터 등)이 모여 브레인 스토밍하는 워크숍을 의미하다.
이벤트 스토밍은 DDD의 전략설계를 가장 쉽게 하는 활동이다.
오프라인 상에서는 화이트보드를 통해 진행할 수도 있고 온라인 상에서는 MSAEZ라는 사이트를 활용할 수도 있다.
이벤트는 시계열처럼 왼쪽에서 오른쪽으로 일어난다.
이벤트는 무조건 커맨드와 짝으로 일어난다.
커맨드가 애그리거트에 영향을 주어 상태가 변경되고 그걸로부터 이벤트가 일어나는 이 세가지가 하나의 페어가 되어 계속적으로 진행되는 형태이다.
Sticker
이벤트스토밍에는 다양한 스티커를 활용하여 시스템을 분석하다.
Event, Command, Aggregate 세 개의 개념이 존재한다.
Event
Event 는 시스템에서 과거에 발생한 어떠한 사건을 의미한다. 사용자도 이벤트를 받을 수 있고 시스템 안에서도 이벤트가 일어날 수 있다.
주로 주황색 스티커로 표현한다.
이벤트는 과거형, 수동형으로 작성한다. (예시 - Added to cart, OrderConfirmed)
Command
command 는 시스템 내부의 상태를 바꾸는 행위에 대한 요청을 말한다. command 는 시스템에서 필수적이다.
파란색 스티커는 상태를 변경시켜 이벤트를 발생시키는 커맨드를 표현할 때 주로 사용된다.
이벤트가 발생되는 소스의 예이다.
커맨드는 외부시스템, 애그리거트, Policy에 상태 변경을 요청할 수 있고 궁극적으로 이벤트가 발생한다.
Aggregate
노란색 스티커로 표현하는 애그리거트는 마이크로서비스 도출에 가장 중요한 키 컨셉이다.
애그리거트는 시스템이 기대하는 책임을 수행하며 일관성을 유지하는 단위를 의미한다. 애그리거트란
클래스를 정의할 때 여러 애트리뷰트를 가지게 된다. (예를들어 상품아이템이라 할때 id, 이름, 수량 등이 포함)
Aggregate 끼리는 오브젝트 레퍼런싱이 아닌 ID 레퍼런싱을 하여 강한 결합도가 아닌 약한 결합도를 가지도록 한다.
앞에 말했던 커맨드가 애그리거트라고 하는 이 오브젝트에 영향을 주어서 이벤트가 발생하는 과정이라고 이해하면 된다.
아이템을 장바구니에 넣는 명령을 내린다. -> Item이라는 애그리거트에 영향을 미쳐서 -> 장바구니에 들어가게 됨 이라는 플로우를 가게된다!
Actor
Actor이란 이벤트를 발생시키는 대상자이다. Command를 날리는 누군가가 있을 것이다. 그 누군가가 Actor이다.
Policy
폴리시(Policy)는 이벤트가 발생한 후 연이어 발생하는 반응형 액션이다. 보라색으로 표현한다.
External System
External System은 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템, 장비를 의미한다. firebase 등이 예시가 될 수 있다.
External System은 핑크색으로 표현한다.
이벤트스토밍 시작하기
자, 이벤트스토밍을 하려고 프로젝트 이해관계자들이 한자리에 모였다. 무엇을 먼저 해야할까? 우왕좌왕,,
이벤트스토밍을 진행하려면 사용자 시나리오가 먼저 정의되는 것이 좋다. 애자일 스크럼과 연계한다면 제품 백로그를 작성하며 사용자 시나리오를 정의하는 것이 된다.
사용자 시나리오를 하나씩 쳐내면서 도메인 이벤트를 도출해내는 작업을 한다면 이벤트스토밍을 원활하게 가져갈 수 있다.
이벤트스토밍은 크게 다음과 같은 순서를 가진다.
- 제품 백로그 작성
- 사용자 시나리오를 쳐내며 도메인 이벤트 도출
- 관련된 도메인 이벤트들을 모아 애그리거트 도출
- 관련된 애그리거트들을 모아 바운디드 컨텍스트 도출
- 컨텍스트 매핑을 활용해 바운디드 컨텍스트 간 관계 표현
- 상세설계 진행
제품 백로그 작성
제품 백로그를 먼저 나열해보자
- 유저는 회원가입을 할 수 있다.
- 유저는 로그인을 할 수 있다.
- 유저는 회원탈퇴를 할 수 있다.
- ....
사용자 시나리오를 쳐내며 도메인 이벤트 도출
사용자 시나리오를 하나씩 쳐내며 해당 시나리오에 대한 도메인 이벤트를 도출한다. 이때 가능하면 커맨드도 붙이면서 한다.
먼저 이벤트들을 쭈욱 나열한다. 빨간색은 external system으로 이벤트가 일어날 때 필요한 외부시스템이 있을 경우 붙인다.
관련된 도메인 이벤트들을 모아 애그리거트 도출
모든 사용자 시나리오에 대해 도메인 이벤트를 도출했다면 관련된 도메인 이벤트를 모아 애그리거트를 도출하는 작업을 진행한다. 그 순서는 다음과 같다.
- 부적격 이벤트를 탈락시킨다.
- 관련된 이벤트를 묶어 애그리거트를 도출해낸다.
관련된 애그리거트들을 모아 바운디드 컨텍스트 도출
애그리거트를 도출했으면 충분한 논의를 통해 관련된 애그리거트를 묶어 바운디드 컨텍스트를 도출한다.
그럼 궁극적으로 이런 형태로 나오게 된다.
모두가 쉽고 간결하게 하나의 그림으로 이해할 수 있다. 또한 마이크로서비스로 연관짓는데 있어서 명확하게 파악 가능하다.
컨텍스트 매핑을 활용해 바운디드 컨텍스트 간 관계 표현
바운디드 컨텍스트를 식별할 때 각 컨텍스트는 내부적으로 응집성이 높고 다른 컨텍스트와는 의존관계가 낮아야 한다는 원칙 하에 설계되지만 각 컨텍스트 간에 아무런 관계가 없다는 의미가 아니다. 이러한 컨텍스트 간의 의존관계를 표현하는 것을 컨텍스트 매핑이라고 한다.
즉 컨텍스트 맵은 하나의 큰 도메인을 여러 바운디드 컨텍스트로 식별하고 이들 간의 관계를 표현한 그림을 의미한다.
우리는 앞서 나온 디자인을 보리스 다이어그램으로 표현하겠다.
애그리거트 간에 통신을 sync나 async로 진행한다.
상세설계 진행
어떤 API를 가져야하고 어떤 데이터를 가져야하고 등 서비스의 상세 스펙을 정의한다.
각각의 서비스마다 도출이 되고 각각 개발팀에서 서비스를 맡아 개발을 진행한다.
마무리
우리는 총 9개의 마이크로서비스를 도출하고 프로젝트를 설계, 개발하였다. 뿌..듯..
MSAEZ 사이트는 이벤트스토밍을 쉽게 해주도록 도와주고 설계 이후 헥사고날 아키텍처까지 뽑아주는 매우 고마운 사이트이다. 활용해보자!
참고자료 & 보면 좋은 것
