Domain-Driven-Design ?
DDD라고 불리는 이 용어는 도메인 주도 설계라는 이름의 도메인과 일치하도록 소프트웨어를 모델링하는 데 중점을 둔 소프트웨어 설계 접근 방식이다.
Domain ?
도메인이란 사전적 의미로 '영역', '집합' 이다. 그리고 비즈니스 Domain은 유사한 업무의 집합이다.
DDD는 기존의 어플리케이션 설계가 비즈니스 도메인에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발 하였다.
그래서 비즈니스를 도메인 별로 나누어 설계를 하여 확장성을 고려하고 모듈간의 의존성은 최소화하고 응집성은 최대화 했다.
도메인 주도 설계의 목적은 소프트웨어의 복잡성을 최소화 하는 것이다.
DDD 의 이벤트 스토밍
* 이벤트스토밍은 Event와 BrainStorming의 합성어로 Domain Expert와 개발 전문가가 함께 모여 워크샵 형태로 진행되는 방법론이다. DDD 방법론 중, 복잡한 UML다이어그램이나 도구 없이 수행할 수 있어 MSA를 구현하는데 가장 최적의 방법론으로 알려져있다.
1. 커맨드 : 도메인 이벤트를 트리거하는 명령
2. 도메인 이벤트 : 발생한 사건
3. 외부 시스템 : 도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템
4. 액터 : 개인 또는 조직의 역할
5. 핫스팟 : 의문사항, 결정하기 힘든 사항
6. 애그리거트 : 도메인 이벤트와 커맨드가 처리하는 데이터, 상태가 변경되는 데이터
7. 정책 : 이벤트 조건에 따라 진행되는 결정, "이벤트"가 발생할 때, "커맨드"를 실행한다.
8. 정보 : 액터에게 제공되는 데이터, 결정을 내리는데 영향을 주는 정보
쇼핑몰을 주제로 DDD 실습
고객의 회원가입부터 물건 결제, 배송까지의 DDD를 알아보자
- 도메인 이벤트 작성
- 도메인이벤트는 시간흐름에 따른 시스템의 동작을 의미한다.
- 상태의 생성 / 변경 / 삭제가 발생하게 만든다.
- 비즈니스 흐름에서 발생한 이벤트에 초첨을 맞춰서 결정한다.
- 과거 시제 또는 명사형으로 기록한다.
- 이벤트들의 발생 순서를 고려하여 배치한다.
- 외부 시스템이 필요한 프로세스
- 명사형으로 작성한다.
- 아이템이 주문되었을 때 결제하는 과정은 외부 결제시스템을 이용한다.
- 결제가 승인되었을 경우 외부 이메일시스템을 통해 결과를 전송한다.
- 커맨드 작성
- 하나의 커맨드에 여러개의 이벤트가 발생할 수 있다.
- 개발자 입장에서 구현하게되는 API가 된다.
- 핫스팟 배치
- 궁금한사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 붙인다.
- 액터를 찾아서 배치
- 액터는 사용자의 역할을 말한다.
- 비즈니스를 수행하는 구체적인 역할을 고려해서 도출하도록 한다.
- 해당 쇼핑몰 사례에서는 사용자를 게스트, 회원, 판매자, 구매자 등으로 구분할 수 있다.
- 애그리거트 정의
- 애그리거트는 가장 작은 도메인 모델의 모듈 단위이다.
- 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소이다.
- 개발자의 입장에서 보면, 도메인의 실체 개념을 표현하는 객체(엔티티)로 구현하게 될 대상이다.
- 커맨드와 도메인 이벤트 사이 상단에 겹쳐서 붙인다.
- 바운디드 컨텍스트 정의 및 정책 도출
- 도메인이벤트와 커맨드, 액터, 애그리거트를 고려해서 경계를 식별한다.
- 애그리거트의 이름으로 컨택스트 이름을 정의한다. 이 과정에서 동일 애그리거트 중심으로 모듈화가 이루어진다.
- 정책을 도출해서 붙인다.
- 정책은 이벤트 뒤에 따라오는 반응적인 비즈니스 로직이다.
- 어딘가의 커맨드를 작동시키는 역할을 하기 때문에 도메인 이벤트와 커맨드 사이에 존재하게 된다.
- 호출 관계의 방향성을 고려한 컨텍스트 매핑
- 바운디드 컨택스트 간의 관계를 파악
- 동기적 호출방식과 비동기적 호출방식을 고려한 표현도 가능
- 동기적(실선): 항상 일관된 데이터필요, 컨텍스트간 의존도가 높음
- 비동기적(점선): 결과적 일관성으로 처리가능한 관계
- 완성된 모습
참조출처 : https://velog.io/@dnflekf2748/DDDDomain-Driven-Design