DDD 이벤트 스토밍 - 크림 클론 프로젝트

개요

본 프로젝트는 Kream 서비스를 클론하는 프로젝트이다. 기본적으로 헥사고날 아키텍처를 코드 베이스로 가져갈 예정이며 점진적으로 CQRS까지 도입해본다. 코드는 깃허브를 통해 작성할 예정이며 본 포스팅에서는 이벤트 스토밍을 통해 바운디드 컨텍스트를 도출하는 과정까지만 간략하게 기술한다. 소스코드는 https://github.com/teamhide 에서 확인할 수 있다. (아직 개발중인점 참고)

범위

모든 기능을 구현하진 않을 것이며 대략 아래와 같은 싸이클을 수행할 수 있도록 필요한 기능만을 구현할 예정이다.

• 유저가 회원가입을 한다.
• 구매자가 상품에 입찰/즉시구매를 한다.
• 판매자가 상품을 입찰/즉시판매를 한다.
• 낙찰된 상품이 배송된다.

도메인 이벤트 식별 - 주황색

• 도메인 이벤트 사이에 순차적인 관계가 있거나 연쇄적으로 발생하는 경우 좌->우로 배치한다. 동일한 비즈니스 정책에 따라 발생하는 이벤트도 이 경우에 해당한다.
• 동시에 발생하는 경우 상->하로 배치한다.

도메인 이벤트는 과거에 일어났던 일을 표현하기 위해 과거 시제를 사용하며 이벤트가 발생한다는 것은 상태가 변경되었음을 의미한다. 본 단계에서 모든 이벤트를 추출하지 않아도 괜찮다. 단계를 진행하며 추가적으로 도출되는 이벤트는 그때마다 추가해도 된다.

이벤트 간 순차적 배치는 도메인 이벤트 식별 이후에 진행해도 된다. 또는 위처럼 식별과 동시에 같이 순차적으로 배치해줘도 된다. 간단하게 설명하자면 다음과 같다.

• 유저
  • 회원가입을 하였다
• 상품
  • 상품을 등록하였다.
  • 상품 정보 변경은 등록 이후 가능하기에 좌->우로 배치했다.
  • 상품 삭제는 등록 이후 가능하기에 좌->우로 배치했다.
• 경매
  • 경매에 상품이 등록되었다.
    • 경매 낙찰/새로운 가격 입찰/경매 취소등의 경우 경매 상품이 등록된 이후에 가능하므로 좌->우로 배치했다.
  • 경매 목록이 조회는 경매 상품 등록과 같은 시간대에 발생할 수 있기에 상->하로 배치했다.
• 배송
  • 판매자가 상품을 배송하였다.
    • 상품 검수의 경우 판매자 상품 배송이후 가능하기에 좌->우로 배치했다.
    • 구매자에게 상품을 배송하는 경우도 검수도 이후에 가능하기에 좌->우로 배치했다.

핫 스팟 도출 - 자주색

이벤트 스토밍 도중 의문 사항이 생기거나 현재 참여자들끼리 결정하기 힘든 사항이 도출될 수 있다. 이러한 내용을 핫 스팟이라고 하는데, 지금 당장 결정하지는 않더라도 잊지않기 위해 위처럼 해당하는 도메인 이벤트 아래쪽에 포스트잇을 추가해준다. 본 예제에서는 기능 자체가 작기 때문에 결제 도중 취소되는 경우 하나만 핫 스팟을 도출하였다.

커맨드 도출 - 파란색

먼저 파란색 포스트잇으로 커맨드를 도출한다. 커맨드는 시스템에서 발생하는 일로써 도메인 이벤트가 발생하는 원인이다. 커맨드는 동사로 작성한다. 본 예제에서는 없는 케이스지만, 하나의 커맨드에 의해 여러개의 이벤트가 동시 또는 연속적으로 발생할 수 있으며 조건에 따라 하나의 커맨드에 여러개의 다른 이벤트가 발생할 수 있음을 유의한다.

외부 시스템 도출 - 보라색

이벤트를 도출하면서 외부 시스템과의 연계를 통해 흐름이 진행되는 경우 분홍색으로 외부 시스템을 명시한다. 예를 들어 회원가입에서 OAuth를 지원하는 경우 OAuth 서비스가 회원가입과 회원가입 되었다 사이에 보라색 포스트잇으로 위치해있을 것이다. 위 예제에서는 외부 시스템이 없으므로 따로 추가하진 않았다.

액터 도출 - 노란색

액터는 사용자 또는 조직, 역할을 담당하는 자를 의미한다. 액터는 추상적인 네이밍이 아닌 비즈니스를 실제로 수행하는 구체적인 역할을 고려하여 도출해야 한다. 액터를 도출하는 도중 식별하지 못했던 도메인 이벤트가 추가로 도출될 수 있는데 이러한 경우에도 추가로 식별되는 사항을 포스트잇으로 추가하면 된다. 

유저, 판매자, 구매자는 실제로는 모두 동일한 유저이다. 하지만 위에서 말했듯이 각 커맨드를 수행할 때 실제로 수행하는 구체적인 역할을 고려했을 때 판매자, 구매자로 나뉘어지기 때문에 위와 같은 네이밍으로 액터를 도출했다.

애그리거트 도출 - 밝은 노란색

애그리거트는 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소로 추후 전술적 설계를 통해 도메인의 실제 개념을 표현하는 객체인 엔티티가 된다. 애그리거트를 도입함으로써 복잡한 도메인 객체들 사이의 관계를 한눈에 파악할 수 있으며 하나의 맥락에서 지켜져야하는 제약사항을 관리할 수 있게 된다. 이러한 과정을 통해 다음 단계인 바운디드 컨텍스트를 쉽게 도출해낼 수 있다.

바운디드 컨텍스트 도출

그동안의 단계를 걸쳐서 도출했던 도메인 이벤트, 커맨드, 액터, 애그리거트를 모두 고려하여 경계를 식별한다. 이렇게 도출된 결과물을 연관있는것끼리 그룹핑하여 각 그룹마다 가지는 명확한 경계를 바운디드 컨텍스트라고 한다. 

Read Model 도출 - 초록색

Read Model은 사용자가 커맨드를 수행함에 있어 결정 근거가 되는 데이터들을 의미한다. 예를 들어 경매 목록 조회의 경우 상품 이름/상품 가격/상품 이미지/입찰 목록 등이 Read Model이 될 수 있다. 사용하는 해당 Model을 통해 정보를 식별하고 해당 정보를 기반으로 다음 커맨드를 결정하기 때문이다.

또한 이는 CQRS패턴으로의 확장에서도 장점을 가져갈 수 있다. 일반적으로 CQRS를 이야기하면 명령과 조회를 분리하는것인데 나아가서 이벤트 소싱까지 다루곤 한다. 하지만 현업에서 이벤트 소싱까지 다루는 경우는 드물고, 여러개의 정규화된 테이블을 역정규화하여 성능에 대한 이점을 가져가기 위한 Read Model을 생성하곤 한다. 이는 또다른 말로 Materialized View라고도 부른다. 

따라서 경매 목록 조회에 위처럼 Read Model을 생성해주었다. 상품 이름/가격/이미지의 정보는 상품 애그리거트에 존재하고 입찰 목록은 경매 애그리거트에 존재한다. 이렇게 나뉘어진 정보를 역정규화하여 하나의 읽기 전용 View로 만들어줄 예정이다.

정책 도출 - 하얀색

정책은 도메인 이벤트 뒤에 따라오는 반응적인 비즈니스 로직으로 어딘가에 존재하는 커맨드를 동작하게 한다. 정책이 호출하는 커맨드는 같은 바운디드 컨텍스트 내에 존재할 수도 있고 다른 바운디드 컨텍스트에 존재할 수도 있다. 따라서 이처럼 정책을 도출함으로써 다른 바운디드 컨텍스트와의 관계를 식별할 수 있다. 일반적으로 정책을 정의할 때는 [도메인 이벤트]할 때는 항상 [커맨드]한다 로 정의한다. 하지만 본 예제에서는 ~정책이라는 네이밍으로 정의하고 각 정책에 대해서 세부적인 목록으로 다시 나누도록 하겠다.

참고로 이렇게 도출한 정책은 코드 구현 시 타 애그리거트 또는 타 시스템에 전파되는 이벤트가 된다.

유저 컨텍스트

유저 컨텍스트의 경우 별도의 정책이 필요하지 않다.

상품 컨텍스트

• 상품 등록 정책
  • 자동으로 경매에 등록되어야 한다.
• 상품 변경 정책
  • 상품 정보가 변경되는 경우 연관된 경매 정보도 변경되어야 한다.
• 상품 삭제 정책
  • 상품이 삭제되는 경우 연관된 경매 정보도 삭제되어야 한다.

경매 컨텍스트

• 경매 낙찰 정책
  • 상품을 배송 대기 상태로 변경해야 한다.
• 경매 취소 정책
  • 상품을 삭제 상태로 변경해야 한다.

배송 컨텍스트

• 판매자 상품 배송 정책
  • 상품을 배송 완료 상태로 변경해야 한다.
• 상품 검수 완료 정책
  • 상품을 배송 준비 상태로 변경해야 한다.
• 구매자에게 상품 배송 정책
  • 상품을 판매 완료 상태로 변경해야 한다.

최종 바운디드 컨텍스트

다음 포스팅에서는 최종적으로 도출된 바운디드 컨텍스트를 기반으로 컨텍스트 맵 생성과 도메인 모델링을 진행해보겠다.

Reference

• DDD START! 도메인 주도 설계 구현과 핵심 개념 익히기
• 도메인 주도 설계로 시작하는 마이크로서비스 개발
• 박재성님 도메인 지식 탐구를 위한 이벤트 스토밍(링크)
• SK C&C - 도메인 주도 설계에서의 전략적 설계(링크)
• SK C&C - 마이크로서비스 모델링 ④ : 이벤트 스토밍을 통한 마이크로서비스 도출(링크)

기타 여러가지 자료들..