도메인 주도 개발

도메인 주도 개발

무엇인가 ?

요구사항, 유즈케이스, 스펙등을 도메인으로 표현하고 해당 도메인들을 도메인 모델로 설계 부터 구현까지의 패턴과 원칙들

객체 지향 + 추가적인 개발론 : oop를 위반하는 경우도 잇음 : 간접 참조, 재사용보단 각각의 모델

 

장점

보통 서비스(어플리케이션) 레이어에 도메인 로직이 담겨있다.

이럴경우 도메인 로직에 대한 응집도가 떨어지고 코드 중복성이 늘어나 가독성 및 유지보수가 어렵게 된다.

비지니스(도메인) 로직을 도메인 모델이 책임지게 하여, 해당 도메인에 대한 응집도를 높이게 되고, 객체 지향적인 설계 원칙( 객체는 기능+상태)을 잘 적용할수 있다.

 

단점

아무래도 oop는 재활용성을 강조하지만 ddd는 각각의 도메인 모델을 추구 함으로 코드에 대한 중복이 늘어날수 있다.

---

전략적 설계

전략적 설계란 구현 관점이 아닌 도메일 모델을 추출하고 경계를 나누는 설계이다.

 

도메인

소프트웨어로 해결하고자 하는 문제 영역

일반 적인 요구사항, 전문용어 등등

ex) 광고, 온라인 쇼핑몰, 온라인서점 등등

도메인은 여러 하위 도메인으로 구성된다.

온라인서점 -> 주문, 회원, 결제 배송 등 여러 하위 도메인으로 구성

 

도메인 모델

도메인을 개념적으로 표현,

기획서, uml, 객체모델

객체지향에서는 주로 객체모델(클래스)로 표현한다.

 

도메인 모델 추출

요구사항 파악, 유즈케이스등을 사용

도메인 추출

* 상태+ 기능으로 도메인 모델 추출

 

Boundery Context

쉽게 말해 서브 도메인 모델의 경계이다.

bounded context 안에 하위 도메인의 모델들이 존재하는것이다. 보통 하나의 하위 도메인이 이상적이다.

bounded context 단위로 서비스를 나누어 개발하게 된다.MSA의 서비스를 나누는 기준이 된다.

 

 

나누는 방법 :

하위 도메인 마다 같은 용어일지라도 의미(사용)가 다르고, 같은 대상 일지라도 지칭하는 용어가 다를수 있다.

이렇게 다른 대상 및 용어를 같은 하나의 도메인 모델로 사용하는것은 올바른 방법이 아니고 표현 할수 없다.

하위 도메인 마다가 각각의 도메인 모델을 만들어야 한다.

• 여러 하위 도메인이 하나의 모델에 섞이면 모델은 여러 요구사항이 반영되어 도메인대한 응집도가 떨어지게 된다.
• 다른 하위도메인에 영향을 주게 된다.

하나의 도메인 모델은 하나의 경계에만 속해야 한다.

이러한 경계를 bounded context라한다.

 

customer, proudct가 bounded context마다 도메인 모델을 가지고 있다.

 

ex) 상품

배송, 결제 하위 도메인에 상품이란 도메인이 있다.

배송에서 상품은 상품의 배송지에 대한 관심이있다. 배송상품 이란 표현을 사용한다.

결제에서는 상품의 결제 금액에 대해관심 있다. 결제 상품 이란 표현을 사용한다.

상품을 같은 도메인 모델을 사용한다면 둘다 지칭하는 용어(표현)도 다르고, 서로에 영향을 주기때문에 같은 도메인 모델을 사용 할수 없다.

---

전술적 설계

기본 요소

도메인 모델은 entity 와 value object로 존재

•  entity
  • 식별자 존재
  • 상태 관리
• value object
  • 불변 객체
  • 상태가 변화하지 않는다.
  • ex) 주소

 

Aggregate

연관된 도메인 모델들의 군집(집합)

하나의 서브 도메인에 연관된 군집(집합)

루트 entity를 갖는다.

도메인 모델은 하나의 aggregate에만 속함

하나의 entity로 가이드 됨

 

Aggregate와 bounded context 연관

bounded context는 보통 하나 aggregate를가짐,

하나의 서브 도메인에 대한 관련된 도메인 모델들의 군집이기 때문이다.

 

Aggregate Root

군집의 대표

aggreagete 모델들의 일관성 유지

aggregate Root를 통해서 다른 도메인 모델들의 대화

Aggreate 참조

* 다른 aggegate root참조는 간접 참조를 통해 의존성 제거

 

Respository

루트 aggegate 조회

aggegate당 하나 존재

 

도메인 서비스

여러 aggegate가 조합되거나 복잡한 로직등을 진행하는 서비스

상태 없이 행위만 존재

사용하는 주체는 응용서비스, aggregate 가 될수잇다.

 

팩토리

객체를 생성해주는 역활

생성 방법

• 도메인 모델내의 팩토리
  • 연관된 에그리거트에서 다른 애그리거트 객체 생성
  • 에그리거트 루트의 팩토리 메소드
  • 같은 바운디드 컨테스트 일경우에 된다
• 서비스의 팩토리
  • 다른 바운디드 컨텍스트와 상호작용 
  • 도메인 서비스(인터페이스)
  • 다른 바운디드 컨테스트의 안티레이어(구현, 인프라영역)

 

---

아키텍쳐

계층형 아키텍쳐

고전적인 아키텍쳐

상위 레이어에서 하위레이어 의존

하위레이어는 상위레이어를 알수 없다.

• 표현 영역 layer
  • 사용자 요청을 받아 응용 서비스에 전달
  • 값 검증
• 응용 서비스 layer
  • 사용자의 요청을 받아 도메인객체를 구하고 위임
  • 트랜잭션 처리
  • 도메인 이벤트 처리(핸들러)
  • 메소드 파라미터 와 값 검증
• 도메인 layer
  • 도메인 모델 클래스, repositry, 도메인 서비스 존재
• 인프라 layer
  • 실제 db, 외부 시스템 인프라 영역
  • 응용 서비스, 도메인 레이어가 의존

DIP(의존성 역전 원칙, dependency of inversion principal)

전통적인 아키텍쳐는 상위(고수준)에서 하위(저수준) 의존하고 하위에서는 상위를 의존하지 않는다.

응용서비스에서 인프라 레이어 의존

이럴 경우 인프라가 변경되면 응용서비스 레이어 변경이 불가피

dip 적용,

• 저수준 모듈이 고수준 모듈에 의존하도록 변경,
• 인터페이스를 상위 레이어에 생성하고, 실구현제가 저수준 모듈(인프라)에 구현함으로써, 의존성 역전
• 단순 인터페이스라고 적용이라고 생각하면 안됨, 인터페이스의 위치가 고수준에 있어야 되는것이다.

---

응용 서비스의 출력

DTO(Data Transfer Object)

프로세스(레이어)간에 데이터 전달

value object가 아닌 구조체

도메인 모델이 아니기에 비지니스 로직은 안됨

 

2가지 방법이 있다. DTO가 주로 사용된다.

 

Domain Model Everywhere

도메인 모델을 모든 계층에 사용

DTO안만들어되는 편리함

Getter, Setter가 필요해지는 케이스가 발생할수있다 , ex ) form

ex ) OSIV

 

Pure Domain Model

클라이언트와 도메인 모델 간의 분리

항상 DTO보단 value Object도 사용 고려 Trade Off

 

---

Anti corruption layer

외부의 응답값을 내부 도메인 모델에 맞게 바꾸는

도메인을 유지

구현은 인프라 영역에, 인터페이스는 도메인영역에

다른 bounded context

• 도메인에 인터페이스 ,구현은 인프라에 해놓고 다른 bc에 service를 주입해서 불러온다.