- 일전의 공부한 내용을 실제로 구현해보면서 공부해보고자 시작한 프로젝트다.
- 이전 글
2. 이벤트 스토밍 진행
이벤트 스토밍?
- DDD에서 마이크로서비스 간의 의존성을 줄이기 위해서 서비스 간 비동기 메시지 기반 이벤트를 활용하는 것이 중요
- 도메인 이벤트를 통한 의존 관계 식별이 쉽지 않다.
- DDD 설계를 가속화할 수 있는 이벤트 스토밍이 있다.
- 이벤트 스토밍은 이벤트 중심으로 이해관계자들이 모여 브레인 스토밍 하는 워크숍을 의미한다.
- 복잡한 도메인을 빠르게 탐색하고 공유하기 위해, 도메인 이벤트를 중심으로 비즈니스 흐름을 시각화하는 방법
이벤트 스토밍의 역할
| 역할 | 설명 |
|---|---|
| Ubiquitous Language 정립 | 도메인 이벤트 중심으로 용어 통일 |
| Bounded Context 탐색 | 연관된 이벤트 흐름 단위로 경계 후보 도출 |
| Aggregate 후보 도출 | 커맨드-이벤트 사이의 엔티티/행위 파악 |
| 설계의 시작점 | 이벤트 → 정책 → 커맨드 흐름으로 설계 기반 마련 |
| 기획자/PO/디자이너/개발자 협업 툴 | 코드가 아닌 “모델” 차원에서 논의 가능 |
진행한 예시
마치며…
정리하면?
- 도메인 주도 설계로 시작하는 마이크로서비스 개발: 핵심 개념과 패턴, 설계, 구현으로 배우는 DDD와 MSA(저자: 한정헌, 유해식, 최은정, 이주영)을 기반으로 진행했다.
- 다수의 이해관계자들이 모여서 대상에 대해서 유비쿼터스 언어로 소통하며 일종의 플로우를 되짚어가는 과정이다.
- 이 과정에서 각기 다른 관점의 생각을 이해할 수 있으며, 의견 합치를 이뤄서 전체 방향성을 맞출 수 있다.
- 추가로 이벤트 스토밍은 ‘상태 변경 중심 모델링’이며 상태 변경에 따라 해당 aggregate의 상태가 어떤 context로 전이 되고 트리거 되는지를 파악하는 데 관심을 두고 있다. (-> 정리하면서 알게 됐고 위 내용에서 query에 관련된 것은 배제해볼 계획이다.)
아쉬웠다.
- 역시나 혼자 진행해야 한다는 점이 아쉬웠다.
- 장점은 다양한 관점 공유, 소통. 그 과정에서 유비쿼터스 언어를 재정립한다는 개념이 들어가 있는데 소프트 스킬을 기를 수 있을만 한 경험이지만 하지 못했다는 것이 아쉬웠다.
그래도?
- 애그리거트, DDD의 엔티티, 값 객체, 도메인 이벤트를 도출하기 위한 작업을 진행해 봤다는 점이 색달랐다.
- 물론 확실하게 파악했냐?라고 하면 “처음 해보는 것이라 어색하다.”가 정답이긴 하지만 기존 내용도 지속적으로 검증할 것이기도 하고 추가적으로 진행하면서 “조금씩 더 다음으면서 나아질 수 있다.”라는 생각이 들었다.