비즈니스 이벤트(도메인 이벤트)를 통해 도메인 이해하기

요구 사항 수집에 대한 DDD 접근 방식은 개발자와 도메인 전문가 간의 공유된 이해 구축을 강조합니다.

그러나 이러한 이해를 발전시키려면 어디서부터 시작해야 할까요?

첫 번째 지침은 데이터 구조보다 비즈니스 이벤트에 초점을 맞추는 것입니다.

비즈니스는 데이터를 정적으로 갖고 있지 않습니다.

비즈니스는 일련의 데이터(도큐먼트) 프로세싱(트랜스폼) 과정입니다.

따라서 데이터들의 변화와 변화 간(함수 간) 관계에 대한 이해가 중요합니다.

 

또한 어떤 일련의 비즈니스 트리거(이벤트 트리거) - push(publish-trigger) or pull(subscribe-observation)를 이해하는 것이 중요합니다.

이 트리거 역할을 하는 것이 바로 도메인 이벤트입니다.

도메인 이벤트는 우리가 모델링하려는 거의 모든 비즈니스 프로세스의 시작점입니다.

예를 들어 "새 주문 양식 수신됨"은 주문 접수 프로세스를 시작하는 도메인 이벤트입니다.

도메인 이벤트는 변경할 수 없는 사실이므로 항상 과거 시제로 작성됩니다.

 

Using Event Storming to Discover the Domain

따라서 공유 모델 구축을 위해선 이벤트를 수집해야 하며, 이벤트 디스커버를 위한 좋은 방법 중 하나가,

이벤트 스토밍 워크샵을 진행하는 것입니다.

 

예시 : Discovering the Domain: An Order-Taking System

노란색 도메인 이벤트 옆에 워크플로 명을 붙입니다.

이벤트 스토밍 과정에서 집중해야 할 것들이 있습니다.

• 비즈니스 모델 공유하기 (모두가 하나의 프로세스에 합의)
• 전체 팀의 업무에 대해 알기 (누락 방지 - 서브도메인 간 상호작용)
• 요구사항과의 차이점 확인
  •  예를들어 주문 이후 고객에게 메일을 보내는 프로세스 누락
• 팀 간의 연결관계 확인
  • 이벤트는 타임라인으로 그룹화할 수 있으며, 이는 종종 한 팀의 출력이 다른 팀의 입력임을 분명히 합니다.

예를 들어, 주문 접수 팀이 주문 처리를 마치면 새로운 주문이 접수되었다는 신호를 보내야 합니다. 이 "주문 완료" 이벤트는 배송 팀 혹은 청구 팀의 입력이 됩니다.

• 리포팅 요구사항에 대한 인식
  • 보고 및 기타 읽기 전용 모델(UI 뷰모델, CQRS)이 이벤트 스토밍 세션에 포함되어 있는지 확인합니다.
  • 모든 비즈니스는 항상 과거에 어떤 일이 일어났는지를 알아야 함.

 

Workflows, Scenarios, Use Cases

• 사용자 관점
  • 시나리오는 고객의 목적(주문하기)입니다. (애자일의 스토리와 비슷함)
  • 유즈케이스는 상호작용과 여러 스텝을 포함한 시나리오의 좀 더 디테일한 버전입니다.
• 비즈니스 관점
  • 비즈니스 프로세스는 회사(비즈니스) 관점에서의 목적입니다. 시나리오와 유사합니다.
  • 워크플로는 비즈니스 프로세스의 일부에 대한 자세한 설명입니다.
    • 즉, 직원(또는 소프트웨어 구성 요소)이 비즈니스 목표 또는 하위 목표를 달성하기 위해 수행해야 하는 정확한 단계를 나열합니다.
    • 한 직원 혹은 팀이 할 수 있는 업무로 단위를 한정하여, 여러 팀에 업무를 나눈 후, 조정하는 작업을 거칩니다.

이벤트를 가장자리로 확장하기 - 이벤트 디스커버

이벤트의 이전, 이후에 일어나는 이벤트들을 찾고, 해당 이벤트를 트리거하는 것이 무엇인지를 계속해서 발견합니다.

이벤트를 가장자리로 최대한 확장하는 것은 누락된 요구 사항을 포착하는 또 다른 좋은 방법입니다. 이벤트 체인이 예상보다 길어질 수 있습니다.

Documenting Commands

무엇이 이벤트를 트리거하나요?

예를 들어, 고객이 주문 폼을 받기를 원하거나 상사가 당신에게 무언가를 요청했습니다.

해당 요청을 DDD에서는 Command라 부릅니다.

Command는 명령어 스타일로 작성합니다.

모든 명령이 실제로 성공하는 것은 아닙니다.

주문 양식이 우편물에서 분실되었거나

상사를 돕기에 더 중요한 일로 너무 바빴을 수 있습니다.

그러나 명령이 성공하면 해당 도메인 이벤트를 생성하는 워크플로가 시작됩니다. 여기 예시들이 있습니다 :

• 커멘드 : X 하라(명령) -> 워크플로 : X 발생시킴 (함수부분 - 위 그림에선 안나타남)-> 이벤트 : X 발생함(과거)
• Command: “Place an order”; Domain Event: “Order placed.”
• Command: “Send a shipment to customer ABC”; Domain Event: “Shipment sent.”
• 명령이 "위젯 Inc에 주문 양식 보내라"이고 워크플로가 주문을 보낸 경우 해당 도메인 이벤트는 "주문 양식이 전송됨"이 됩니다.

 이벤트는 일부 비즈니스 워크플로를 시작하는 명령을 트리거합니다. 워크플로의 출력은 몇 가지 더 많은 이벤트입니다. 물론 이러한 이벤트는 추가 명령을 트리거할 수 있습니다.

입력과 일부 출력이 있는 파이프라인과 같은 비즈니스 프로세스에 대한 이러한 사고 방식은 함수형 프로그래밍이 작동하는 방식과 매우 잘 맞습니다.

이 접근 방식을 사용하면 주문 처리 프로세스가 다음과 같이 보입니다.

 

실제로는 Error Handling을 고려해야 합니다.

 

모든 이벤트가 명령과 연결될 필요는 없습니다.

회계 시스템의 MonthEndClose 또는 창고 시스템의 OutOfStock과 같은 일부 이벤트는

스케줄러 또는 모니터링 시스템에 의해 트리거될 수 있습니다.