D를 아십니까?

DDD라고 불리는 이 용어는 도메인 주도 설계라는 이름의 도메인과 일치하도록 소프트웨어를 모델링하는 데 중점을 둔 소프트웨어 설계 접근 방식이다.

특징

• DDD는 계속해서 발전하는 모델의 구현에 초점을 맞춘다.
• 핵심 도메인 및 도메인 논리에 프로젝트의 주요 초점을 둔다.
• 도메인 모델에 기반한 복잡한 디자인
• 특정 도메인의 개념적 모델을 계속해서 개선하기 위해 기술 전문가와 도메인 전문가 간의 창의적인 협력을 한다.

Domain이란 무엇인가?

도메인이란 사전적 의미로 '영역', '집합' 이다. 그리고 비즈니스 Domain은 유사한 업무의 집합이다.

DDD란?

기존의 어플리케이션 설계가 비즈니스 도메인에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발 하였다.
그래서 비즈니스를 도메인 별로 나누어 설계를 하여 확장성을 고려하고 모듈간의 의존성은 최소화하고 응집성은 최대화 했다.

도메인 주도 설계의 목적은

소프트웨어의 복잡성을 최소화 하는 것이다.그리고 요구사항을 쉽게 반영하고 소통이 원활하게 이루어질 수 있다.

DDD

소프트웨어는 사용이 되어야 가치가 있는 것이다. 그래서 사용자가 이해하고 원하는대호 목적에 맞게 사용할 수 있도록하는 것을 목표로 해야 한다.

DDD를 프로젝트에 반영하기 위해서는 도메인을 우선으로 설계를 해야하고 그 도메인을 바탕으로 개발을 진행해야 한다.

DDD 실습 해보기(이벤트 스토밍)

8가지의 도메인 주도 설계의 주요 용어가 있다.

1. 도메인 이벤트: 발생한 사건

2. 커맨드: 도메인 이벤트를 트리거하는 명령

3. 외부 시스템: 도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템

액터: 개인 또는 조직의 역할

핫스팟: 의문사항, 결정하기 힘든 사항

• 궁금한사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 붙인다.

애그리거트: 도메인 이벤트와 커맨드가 처리하는 데이터, 상태가 변경되는 데이터

정책: 이벤트 조건에 따라 진행되는 결정, "이벤트"가 발생할 때, "커맨드"를 실행한다.

정보: 액터에게 제공되는 데이터, 결정을 내리는데 영향을 주는 정보

쇼핑몰을 주제로 DDD실습해보기

간단하게 생각해서 고객이 회원가입을 해서 물건을 결제, 배송까지의 Domain-Driven-Design을 해보자.

도메인 이벤트 작성

• 도메인이벤트는 시간흐름에 따른 시스템의 동작을 의미한다.
• 상태의 생성 / 변경 / 삭제가 발생하게 만든다.
• 비즈니스 흐름에서 발생한 이벤트에 초첨을 맞춰서 결정한다.
• 과거 시제 또는 명사형으로 기록한다.
• 이벤트들의 발생 순서를 고려하여 배치한다.

다음과 같이 도메인 이벤트를 작성 하였다. 정말 단순하게 소비자가 회원가입을 해서 물건을 검색 후 장바구니에 추가하고 장바구니안에 있는 물건들을 구매해서 배송까지의 과정이다.

외부 시스템이 필요한 프로세스 추가

• 명사형으로 작성한다.
• 아이템이 주문되었을 때 결제하는 과정은 외부 결제시스템을 이용한다.
• 결제가 승인되었을 경우 외부 이메일시스템을 통해 결과를 전송한다.

결재에 필요한 시스템과 구매를 했다는 이메일 시스템, 택배를 배송 해주는 시스템을 작성했다.

커맨드 작성

• 하나의 커맨드에 여러개의 이벤트가 발생할 수 있다.
• 개발자 입장에서 구현하게되는 API가 된다.

핫스팟 배치

• 궁금한사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 붙인다.

액터를 찾아서 배치

• 액터는 사용자의 역할을 말한다.
• 비즈니스를 수행하는 구체적인 역할을 고려해서 도출하도록 한다.
• 해당 쇼핑몰 사례에서는 사용자를 게스트, 회원, 판매자, 구매자 등으로 구분할 수 있다.

너무 구매자 밖에 없는거 같아서 판매자 이벤트도 추가 하였다.

문장으로 액터, 커맨드, 이벤트를 검토

{구매자:액터}가 상품{상품결제:커맨드}하면 {장바구니 물건 결제됨:도메인이벤트}이벤트가 발생하고 이어서 외부 시스템{결제 시스템:외부시스템} 실행된다.

애그리거트 정의

• 애그리거트는 가장 작은 도메인 모델의 모듈 단위이다.
• 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소이다.
• 개발자의 입장에서 보면, 도메인의 실체 개념을 표현하는 객체(엔티티)로 구현하게 될 대상이다.
• 커맨드와 도메인 이벤트 사이 상단에 겹쳐서 붙인다.

바운디드 컨텍스트를 정의하고 정책 도출

• 도메인이벤트와 커맨드, 액터, 애그리거트를 고려해서 경계를 식별한다.
• 애그리거트의 이름으로 컨택스트 이름을 정의한다. 이 과정에서 동일 애그리거트 중심으로 모듈화가 이루어진다.
• 정책을 도출해서 붙인다.
• 정책은 이벤트 뒤에 따라오는 반응적인 비즈니스 로직이다.
• 어딘가의 커맨드를 작동시키는 역할을 하기 때문에 도메인 이벤트와 커맨드 사이에 존재하게 된다.

호출 관계의 방향성을 고려하여 컨택스트 매핑

• 바운디드 컨택스트 간의 관계를 파악
• 동기적 호출방식과 비동기적 호출방식을 고려한 표현도 가능
• 동기적(실선): 항상 일관된 데이터필요, 컨텍스트간 의존도가 높음
• 비동기적(점선): 결과적 일관성으로 처리가능한 관계

예제 완성

DDD를 이용해서 설계를 하면 액터, 도메인에 따라 설계가 가능하고 마이크로서비스를 위한 설계가 되기도 한다.