DDD와 어플리케이션 이벤트 스토밍

DDD (Domain Driven Design)

소프트웨어가 복잡한 것은 도메인이 복잡하기 때문이다.

그래서 도메인 전문가(기획자)와 개발자가 어떻게 협업하느냐가 중요하다.

이를 위해 보편언어를 사용하고, 모델 주도 디자인을 해야 한다.

단순히 Entity, value object, aggregate와 같은 구체적 개념이라기보단 개발 프로세스에 대한 철학이다.

 

step1. 보편언어 정의

도메인에 대한 어휘를 이해관계자(기획자, 개발자, 분석가 등등)들이 공통적으로 이해할 수 있도록 정의한다.

 

step2. 모델 주도 설계

도메인 분석과 설계의 간극은 최소화한다. 분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지한다. 모델 = 코드

 

도메인이란?

• 영역, 집합
• 비즈니스 Domain
• 예를 들면 주문, 고객, 주소관리 등등과 같이 분리할 수 있다.

 

전략적 설계 in DDD

• 비즈니스의 상황(Context: 대상자, 상황)에 맞게 설계한다.
• 모든 Context를 이벤트 스토밍을 통해 공유한다.
• 각 Context를 그룹핑한다. (Bounded context)
• 컨텍스트 매핑을 통해 Bounded context간의 관계를 정의한다.

>> 전략적 설계의 결과물 : 도메인 모델 (서비스를 추상화한 설계도 / 분리와 연결)

 

 

전술적 설계 in DDD

• 더 상세한 부분(Bounded Context 내부) 모델링
• Model Driven Design
• Aggregate pattern
• 계층형 아키텍처를 통한 도메인 모델 분리
• 도메인 이벤트를 통해 도메인을 보다 명확히 모델링

 

 

어플리케이션 이벤트 스토밍

step1. Domain Event 정의

• 이벤트는 Actor가 Action을 해서 발생한 결과이다.
• 각자 생각나는 Event를 적고 더이상 생각이 안 날때까지 붙인다.
• 서로 상의하면서 중복된 것을 없애거나 합친다.
• 이벤트가 발생하는 시간 순서대로 붙인다. 동시 수행되는 이벤트는 수직으로 붙인다.
• 비즈니스 용어로 무슨 일이 발생했는지를 적는 것이지 시스템 내에서 발생되는 것을 찾는 것이 아니다.

 

step2. 프로세스 그룹핑

• 동일한 비즈니스 주제(업무 프로세스)로 이벤트들을 그룹핑한다.
  보라색 포스트잇에 프로세스명과 간략 설명을 기술한다.
• 비즈니스적으로 중요한 핵심 프로세스에 집중한다. 핵심 프로세스에 중요한 이벤트가 누락되지 않았는지 검토한다.
• 지원 프로세스는 너무 자세하게 이벤트를 식별하지 않는다.

ex)

음식점 선택	음식 메뉴 선택	배송지 입력	주문 접수
주문 내역 조회	예상 소요 시간 입력
배송 완료 후 배송 버튼 클릭
주문 내역 조회	주문 취소

 

step3. Command 정의

• 사용자의 행위가 Command가 된다. Command는 일반적으로 '무엇을 CRUD 요청한다' 또는 '무엇을 XX한다'의 형태이다.
• 각 이벤트별로 그 이벤트를 발생시키는 Command가 무엇인지 생각하여 이벤트 왼쪽에 붙인다. Command 하나에 1개 이상의 이벤트가 발생할 수 있다.

 

step4. Trigger 정의

• Command를 수행하는 Actor를 정의한다. Actor를 Command의 왼쪽 하단에 겹쳐서 붙인다.
• 이벤트 발생과 관련된 외부 시스템이 있다면 이벤트의 우측 상단에 겹쳐서 붙인다.

ex)

 

step5. Aggregate 정의

• Command 수행을 위해 CRUD 해야하는 데이터 객체를 정의한다.
• Command를 수행해서 이벤트를 발생시키려면 어떤 데이터가 필요한지 각 Command와 이벤트 사이의 위에 적는다.

ex)

 

step6. Bounded Context 정의

• 지금까지 뽑힌 메타데이터를 그룹으로 묶는다.

ex)

 

step7. Context Map 작성

• Bounded context간의 관계를 도식화 한다.

ex)

[음식점] <메뉴정보요청---------------- [주문] ----------------배송요청/취소요청> [배송]