DDD 설계 - 이벤트 스토밍
이전 프로젝트인 ‘공연 예약 서비스’는 DDD 설계를 목표로 했었다. 하지만 구글링을 통한 간단한 선행 학습으로 시작했기 때문에 미흡한게 많았다.
‘공연 예약 서비스’와 달리 이번 프로젝트는 DDD의 개념과 여러 방법을 관련 서적으로 학습하고, 실제 적용해 보고자 한다. 다음은 DDD를 학습하기 위해 참고한 서적이다.
DDD로 설계할 때, 가장 먼저 하는 일은 핵심 도메인을 이해하는 것이다. 전략적 설계는 이런 도메인을 잘 나누는 과정을 의미한다. 비즈니스 도메인을 분석해서 하위 도메인을 분류하고 모델링한다.
이 과정에서 도메인 분석을 위해 이벤트 스토밍을 사용할 수 있다. 이벤트 스토밍의 과정은 아래와 같다. 순서는 서적마다 차이가 있으며 반드시 적혀있는 순서대로 할 필요는 없다. 작업은 miro를 사용하여 진행했다.
이벤트 스토밍 순서
- 도메인 이벤트 찾기
- 외부 시스템/외부 프로세스 찾기
- 커맨드 찾기
- 핫스팟 찾기
- 액터(사용자/역할) 찾기
- 애그리게이트 찾기
- 바운디드 컨텍스트 정의하기
- 컨택스트 매핑하기
1. 도메인 이벤트 찾기
‘도메인 이벤트 찾기’는 프로젝트에서 발생할 수 있는 모든 이벤트를 찾는다. 물론 한 번에 전부 찾을 수는 없다. 이벤트 스토밍 자체가 긴 시간 피드백을 거쳐 만들어가는 과정이기 때문에 찾을 수 있는 만큼 찾는다. 나중에 떠오르는 이벤트는 그때 추가하자.
도메인 이벤트의 포스트잇은 오렌지색이다. 생각나는 이벤트를 오렌지색 포스트잇에 적어놓는다. 이때 중요한 것은 비즈니스의 시간의 흐름에 따라 도메인 이벤트를 도출하는 것이다. 이벤트 작성 명은 과거형 동사로 작성한다. 정리한 특징은 다음과 같다.
- 오렌지 색 포스트잇에 도메인 이벤트를 작성
- 비즈니스 흐름에 다라 도메인 이벤트 도출
- 이벤트는 과거형 동사로 작성
1) 생각나는 도메인 이벤트 도출
도메인 이벤트를 ‘오렌지색 포스트잇’에 과거형 동사로 떠오르는 대로 작성한다. 이벤트 내용은 시간이 지남에 따라 바뀔 수 있으니 부담가지지 말고 작성하자.
2) 시간의 순서로 정리
도메인 이벤트를 좌에서 우로 시간의 순서대로 정리한다.
2. 외부 시스템/외부 프로세스 찾기
도메인 이벤트를 도출하다보면 외부 시스템과 연계가 필요할 때가 있다. 이런 경우 핑크색 포스트잇에 작성하여 이벤트 오른쪽 상단에 붙이고 화살표를 그린다. (예시는 다른 프로젝트이다)
3. 커맨드 찾기
도메인 이벤트를 찾은 후, 이벤트를 동작하게 하는 커맨드(Command)를 찾는다. 커맨드는 파란색 포스트잇을 사용한다. 커맨드는 도메인 이벤트를 동작하게 하는 명령형으로 동사 형태로 작성한다.
도메인 이벤트의 좌측에 커맨드 포스트잇을 추가한다.
4. 핫스팟 찾기
이벤트 스토밍 과정에서 의문 사항이 생길 수 있다. 지금 결정하기 힘들거나 다른 부서에 문의가 필요한 내용들이 그런 것들인데. 이런 내용은 보라색 포스트잇으로 표시한다. 보라색 포스트잇 말고도 다이아몬드로 표시할 수 있는데. 취향에 맞게 표시하면 된다.
Live 강의에 매진이 필요한지, Live 강의를 취소했을 경우, 예약 대상자에게 알림을 보낼지와 같은 지금 결정하기 애매한 내용을 표시했다.
5. 액터(사용자/역할) 찾기
이제 액터(Actor)를 도출해야 하는데. 액터는 커맨드를 호출하는 사용자를 의미한다. 가능한 추상적이지 않고 구체적인 역할을 도출해야 한다. 예를 들어, 회원이나 관리자보다 판매자, 구매자, 상품 관리자, 배송 관리자와 같이 명확한 역할자를 도출하자.
액터는 노란색의 작은 포스트잇으로 커맨드의 왼쪽 아래에 붙여준다. 사실 일반 회원도 강의를 올릴 수 있도록 계획했는데. 구체적인 역할 구분을 위해 강사를 추가했다.
6. 에그리게이트 찾기
에그리게이트란, 비즈니스 도메인에서 한 트랜잭션 안에 일관적인 상태를 유지해야 하는 객체만 포함된 개념이다. 에그리게이트는 노란색 포스트잇을 사용하여 표시한다. 액터와 마찬가지로 구체적인 표현으로 도출하는 것이 좋다.
7. 바운디드 컨텍스트 정의하기
에그리게이트를 식별한 후, 이름이 같거나 유사한 것들을 볼 수 있다. 이처럼 이름이 같거나 유사한 에그리게이트를 다른 에그리게이트와 구분하여 경계를 그린다. 각 바운디드 컨텍스트에는 이름을 부여하는데. 바운디드 컨텍스트 내의 에그리케이트 이름으로 정의한다. 만약 바운디드 컨텍스트 내에 여러 에그리게이트 이름이 존재한다면 전체를 아우를 수 있는 대표 이름으로 선정한다.
식별된 바운디드 컨택스트는 마이크로서비스의 후보가 될 수 있다.
8. 컨택스트 매핑하기
이전 과정으로 대략적인 바운디드 컨택스트 식별되면 각 바운디드 컨택스트 간의 관계를 표현할 차례이다. 컨택스트 간의 관계는 호출 관계의 방향을 고려해야 한다. 호출 관계의 방향이란 [주문 → 상품 → 배송] 처럼 주문 컨택스트는 상품을 호출하고 배송을 호출하는 순서를 말한다.
호출하는 방식은 동기와 비동기 방식이 있으며, 동기는 실선, 비동기 호출은 점선으로 표현한다. (예시는 다른 프로젝트이다)
마무리
‘도메인 주도 설계 첫걸음’에 이벤트스토밍의 진행 과정은 반드시 따라야 하는 고정된 규칙이 아니라 가이드라고 했다. 그러니 언제든지 순서에서 벗어나 작업하는게 좋다. 지금 만들려는 프로젝트를 DDD의 이벤트 스토밍을 사용하여 설계하는 과정을 거쳤다. 사실 혼자 프로젝트를 설계하고 진행하다보니, 프로젝트의 세부적인 요구사항이 그날에 따라 바뀌는 편이다.
밥을 먹다 ‘이 기능이 있는게 좋겠는데?’를 반복하다보니 전체적인 설계가 늦어지고 있다. 하지만 이벤트 스토밍을 하면서 좋은점은 생각만 하던 설계가 정리가 되는 기분이다.
이벤트 스토밍이 마무리된 다음으로는 아키텍처 설계나 도메인 모델링을 진행할 예정이다. :)