본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
이번 강의에서는 요구사항 분석과 아키텍처 설계를 다루었다. 요구사항 분석에서는 간단히 기능과 api를 설계하고 그것을 기반으로 이벤트 기반 아키텍처에 반영을 진행했다. 강의에서 요구사항 분석 및 설계 내용이 나온김에 이벤트 스토밍에 대해 더 알아보았다.
이벤트 스토밍이란
이벤트 스토밍은 이탈리아 프로그래머 Alberto Brandolini가 제안한 협업 워크숍 기법이다. 복잡한 비즈니스 도메인을 빠르게 탐색하고 모델링하는 방법으로, 클래스나 데이터베이스가 아닌 도메인 이벤트와 비즈니스 프로세스에 중점을 둔다. 코드 없이 진행되어 개발자뿐만 아니라 도메인 전문가, 기획자 등 모든 이해관계자가 참여할 수 있다.
전통적인 DDD 접근법이 도메인 객체(명사)부터 시작하는 것과 달리, 이벤트 스토밍은 도메인 이벤트(동사)에 집중한다. 이는 시스템에 존재하는 것보다 시스템에서 일어나는 일을 강조하여 비즈니스 프로세스와 자연스럽게 정렬된다.
핵심 구성요소
| 색상 | 구성 요소 | 설명 |
| 주황색 | 도메인 이벤트 | 비즈니스적으로 의미 있는 사건, 과거 시제 사용 |
| 파란색 | 커맨드 | 이벤트를 발생시키는 명령이나 액션 |
| 노란색(작은) | 액터 | 커맨드를 실행하는 사용자나 시스템 |
| 연보라색 | 정책 | "~할 때마다" 형태의 비즈니스 규칙 |
| 노란색(큰) | 애그리거트 | 비즈니스 규칙을 담고 커맨드에 반응하는 엔티티 |
| 초록색 | 리드 모델 | 의사결정에 필요한 정보/데이터 |
| 분홍색 | 외부 시스템 | 레거시 시스템이나 외부 API |
| 자주색 | 핫스팟 | 해결되지 않은 문제나 위험 사항 |
이벤트스토밍의 프로세스 중심 패러다임
이벤트스톰밍은 도메인 모델링의 패러다임 전환을 의미한다. 도메인 객체(명사)부터 시작하는 대신, 중요한 도메인 이벤트(동사)를 식별하는 것으로 시작한다. 이 접근법은 아래와 같은 장점을 제공한다.
결과 중심
- 시스템에 존재하는 것보다 발생하는 일에 중점을 두어, 이벤트스톰밍은 자연스럽게 비즈니스 프로세스와 사용자 스토리에 부합한다.
협업적 모델링
- 다양한 이해관계자가 참여하는 워크숍을 통해 도메인에 대한 공유된 이해를 촉진한다.
서사적 흐름
- 이벤트스톰밍은 도메인 모델링에 스토리텔링 방식을 도입하여 복잡한 도메인을 모든 이해관계자가 더 쉽게 접근할 수 있게 한다.
DDD Tactical Patterns와의 관계
이벤트 스토밍 개념과 DDD 전술적 패턴의 매핑은 다음과 같다.
Direct Correspondences
- 도메인 이벤트 (주황색): DDD의 Domain Events와 완벽히 일치
- 애그리거트 (노란색 큰): DDD의 Aggregates에 대응하지만 구조적 디테일은 부족
Implied Concepts
- 엔티티: 이벤트 설명이나 커맨드에서 암시됨
- 밸류 오브젝트: 이벤트나 커맨드 세부사항에 포함되지만 명시적이지 않음
- 도메인 서비스: 복잡한 정책이나 여러 애그리거트 간 상호작용에서 암시됨
Concepts Not Directly Represented
- 리포지토리: 이벤트 처리와 커맨드 실행에서 암시되지만 명시적이지 않음
- 팩토리: 생성 관련 커맨드에서 암시될 수 있음
Unique EventStorming Concepts
- 커맨드 (파란색): 애그리거트의 메서드 호출이나 도메인 서비스의 파라미터로 변환
- 정책 (연보라색): 도메인 서비스, 명세(Specification), 또는 애그리거트 내부 비즈니스 규칙으로 변환
- 외부 시스템 (분홍색): Anti-Corruption Layer나 특정 통합 패턴으로 변환
- 리드 모델 (초록색): 특정 조건의 객체를 요청하는 메서드를 제공하는 리포지토리로 변환
DDD 맥락에서의 EventStorming 강점
- 도메인 탐색(Domain Exploration): EventStorming은 도메인의 “동적인 측면(시간의 흐름 속에서 일어나는 일)”을 드러내는 데 강하며, 지식 정제(knowledge crunching)를 강조하는 DDD를 보완한다.
- 보편 언어(Ubiquitous Language): 워크숍의 협업적 성격 덕분에 이해관계자 간 공유 언어를 만드는 데 도움이 된다.
- 바운디드 컨텍스트 식별(Bounded Context Identification): 이벤트 흐름을 따라가다 보면 도메인 경계가 자연스럽게 드러나 바운디드 컨텍스트를 식별하는 데 유리하다.
- 이벤트 기반 아키텍처와의 정합성: EventStorming은 DDD에서 자주 선택하는 이벤트 기반 아키텍처(EDA), CQRS, 이벤트 소싱(Event Sourcing) 같은 스타일과 자연스럽게 맞물린다.
한계와 보완 전략
- 구조적 디테일 부족
- 애그리거트/엔티티/값 객체의 내부 구조를 자세히 표현하지 못한다.
- 보완: 필요 시 UML 다이어그램을 추가로 사용하거나, 구조 정보를 담는 추가 포스트잇 타입을 도입한다.
- 일부 DDD 개념의 암묵적 표현
- 리포지토리, 팩토리, 일부 도메인 서비스는 EventStorming에서 암묵적으로만 나타난다.
- 보완: 중요한 경우, 다른 모델링 기법을 병행해 이런 개념들을 명시적으로 기록한다.
- 높은 추상화 수준
- 의사소통에는 유리하지만, 상세 설계 단계에서는 부족할 수 있습니다.
- 보완: EventStorming을 “출발점”으로 인식하고, 필요한 영역은 다른 기법으로 더 깊게 파고든다.
DDD 설계 프로세스에 EventStorming을 통합하는 방법
DDD 맥락에서 EventStorming을 효과적으로 활용하려면 다음 흐름이 좋다.
- 빅 픽처 EventStorming으로 시작: 초기 도메인 탐색과 바운디드 컨텍스트 식별에 활용
- 프로세스 레벨 EventStorming으로 진행: 식별된 바운디드 컨텍스트 안의 구체 프로세스를 더 깊게 탐색
- 디자인 레벨 EventStorming으로 전환: 시스템 설계를 본격화하며 애그리거트와 핵심 도메인 이벤트를 식별
- 추가 모델링 보완: UML 또는 커스텀 표기법으로 애그리거트/엔티티/값 객체의 구조적 디테일을 보강
- 반복과 정제: EventStorming과 다른 모델링 기법을 오가며 모델을 지속적으로 다듬기
- 구현과의 정렬: 선택한 아키텍처/패턴과 모델이 일관되게 맞물리는지 확인
참고 출처
- https://medium.com/building-inventa/how-we-used-event-storming-meetings-for-enabling-software-domain-driven-design-401e5d708eb
- https://www.youtube.com/watch?v=gihxS6eE1DM
- https://medium.com/@lambrych/eventstorming-for-domain-driven-design-strengths-and-limitations-3f0b49009c38
