[MSA-기획/설계] DDD기반 설계 EventStorming 도입하기

작성: 2025.05.20

🌈이벤트 스토밍 도입 배경

MSA 기반 중고거래 플랫폼을 만들기로 하여 ERD를 구상하기로 했습니다.

처음에는 무작정 서비스를 도메인 별로 나누었더니 회원 + 프로필 / Auth / 상품+관심상품+상품검색/ 거래+배송/ 알림 / 신고 + 관리자 기능 / 커뮤니티, 커뮤니티 검색 / 채팅 이렇게 9개로 구분을 했었습니다.

그런데 이렇게 자잘하게 나누다보니 마이크로서비스 간의 호출이 너무 잦게되어 오버스펙으로 판단이 되었기에 이에 대해서 멘토님께 “회원을 처리할 때 인증 인가 부분을 Auth 서비스에서 책임지게 하고, Memeber 서비스에서는 회원 등록, 수정, 탈퇴 등 프로필 관리만 할 수 있도록 나누는 것이 괜찮을까요?” 라고 질문을 드렸었고, 이에 대한 답은 “너무 오버스펙인 것 같아요 너무 잘게 쪼개면 서비스 간의 호출이 너무 잦게 되어서 관리도 힘들고 msa를 할 이유가 없어집니다. ” 였습니다.

 

 

처음에 이렇게 나누고자 했었다.

이에 대해 멘토님께서 이벤트 스토밍기법을 추천해주셨고, 이를 적용해보면 서비스 구조가 자연스럽게 잡힐 것이라고 해주셨고, 팀원들과 만나서 해당 기법으로 설계를 다시 해보았기에 이에 대해서 말해보고자 합니다.

이벤트 스토밍이란?

여러가지 색의 메모지에 자신이 생각하는 중요 이벤트, 사용자, 명령의 비즈니스 규칙을 적어 벽에 붙이면서 진행하는 워크숍입니다.

메모지를 붙이면서 스몰톡이 일어나고, 그것을 토대로 구성원 모두가 도메인을 학습하게 되는 것이 목적입니다.

복잡한 비즈니스 도메인을 빠르게 탐색하고 학습할 수 있는 방법입니다.

 

진행을 하기 전에 모두 처음 해보는 기법이라, 관련 글과 아래 영상을 찾아 카톡방에 공유해서 방법을 익힌 상태로 만나자고 했습니다.

 

https://www.youtube.com/watch?v=hUcpv5fdCIk&ab_channel=OpenUP-오픈업

 

주황색 - 도메인 (타임라인별로)
노란색 - 구체적인 페르소나
분홍색 - 외부 시스템
자주색 - 타임라인별로 구별할 때 발생한 갈등을 시각화 → 팀원들과 고민할 만한 것들
파란색 - 커맨드 or 액션
초록색 - 액터가 액션을 내리는데 필요한 정보
보라색 - ~정책 ; 할때마다라는 단어로 시작, 도메인 이벤트와 커맨드 사이에 위치 
연노란색 - 에드리게잇 또는 비즈니스 규칙

 

위는 포스트잇의 색상별 개념입니다.

현재 어느 정도 디자인이 되었기 때문에 피그마를 큰 화면에 띄우고,

자세하게 작성된 유저스토리를 동시에 보면서 이벤트 스토밍을 시작했습니다.

 

2. 도메인 이벤트를 타임라인 순으로 정리 & 스몰 톡 시작

시간은 왼쪽에서 오른쪽으로 흐르고, 위에서 아래로 평행한 시간으로 표현했습니다.

또한 정리를 하게 되면서 팀원들과 이야기를 나누면서 이럴땐 어떻게 할까? 등 회의를 하기 시작했습니다.

이때 자주색(자주색이 없어서 분홍색)포스트 잇에 어떤 부분에 대해 스몰톡이 오고 갔는지를 적어놓았고, 해당 부분들을 해결해 나가면서 공통된 이해를 도출할 수 있었습니다.

 

알림 탭에는 어떤 알림이 들어가야하는가?

• 이때 채팅 알람은 푸쉬알림으로만 하자
• 거래 상태와 커뮤니티 관련 알림만 탭에 넣자

거래 요청 버튼은 판매자 , 구매자 모두에게 활성화 시킬까?

• 구매자에게만 활성화 시키자

위와 같이 불확실한 도메인을 스몰톡을 통해서 해결해 나갔습니다.

3. 액터, 커맨드, 애그리게잇(Aggreate), 정보, 정책 설정, 외부 시스템 사용 표시 하기

액터

 

그 후에는 액터를 결정하여 노란색 포스트잇에 작성하였습니다.

우리는 판매자, 구매자, 그리고 사용자 (판매자+ 구매자 + 그 외의 회원들) 이렇게 3가지로 구분을 하였습니다.

 

커맨드

 

또한 커맨드를 식별하여 파란색 포스트잇에 작성했는데,

이벤트가 시작되는 시점의 명령을 현재 동사로 표현하였습니다.

 

 

애그리게이트

 

그런 다음 애그리게이트로 관련된 객체들을 하나의 그룹으로 묶었습니다.

크게 회원, 알림, 커뮤니티, 상품, 채팅, 거래 로 6개로 나뉘었습니다.

 

정보

 

해당 이벤트가 시작할 때 필요한 정보들을 초록색 포스트잇에 작성했습니다.

 

 

정책

 

거래 상태 부분에서 배송 완료 후 3일 내에 구매 확정을 클릭하지 않는다면 자동으로 거래 상태가 완료 된다는 정책 또한 작성하여 붙였습니다.

 

 

외부시스템 사용 표기

 

전화번호 인증할 때 사용되는 api와 결제에 필요한 api, 송장번호 조회 및 배송현황 확인할 수 있는 api 또한 작성하여 붙여놓았습니다.

그리하여 아래처럼 진행이 완료되었습니다.

 

 

 

이벤트 스토밍 진행후 느낀점

포스트잇으로 설계를 하다보니 집중이 더 잘되는 느낌을 받았고, 이벤트 스토밍을 하기 전에 비해 한 후의 설계 체계가 잡힌 것 같아서 의미있는 시간이었던 것 같습니다.

팀원들과 도메인 내용을 공유하여 도메인을 학습하게 되어 좋았다. 또한 이렇게 설계를 하면서 감이 잡히지 않았던 마이크로 서비스 구분을 어떻게 쪼개야할지 자연스럽게 감이 잡혔습니다.

그러나 포스트잇 색상의 부재와 온라인으로 회의할 시 게속 펼치면서 이야기를 할 수 없었기에

깔끔하게 피그잼으로 옮기기로 했습니다.

팀원 모두가 공통된 이해를 가지는 효과를 얻을 수 있었던 것 같아서 너무 유용했던 시간이었던 것 같고,

처음 진행한 방법이라 미숙했지만, 효과는 그 이상이었다고 생각이 들었습니다!!

 

피그잼으로 옮긴 결과물입니다!

 

이번 글에서는 도메인 설계와 이벤트 스토밍을 통해
서비스 경계를 정의하고, 도메인 중심의 구조를 완성했습니다.

다음 글부터는 설계한 구조를 코드와 인프라로 옮겨가는 과정을 다루며,
아래 순서로 시리즈를 이어갈 계획입니다.

 

🚀 MSA 프로젝트 시리즈

1. DDD기반 설계 EventStorming 도입하기  –  (현재 글)
2. MSA 환경 구성 – 각 서비스의 공통 환경과 인프라 구조 설정
3. gRPC 통신 구조 구현 – API Gateway ↔ 서비스 간 통신 흐름
4. Transactional 트러블슈팅 – gRPC 트랜잭션 및 롤백 처리 문제
5. S3 Presigned URL 이미지 전송
6. 프론트–백엔드 연동
7. CI/CD 자동 배포
8. ECS 배포 및 트러블슈팅