[DDD-Start] Ch02. 아키텍처 개요

DIP (Dependency Inversion Priciple)

• 도메인이 인프라스트럭처 계층에 의존하지 않는 방법
  . 전략패턴과 유사한 방식같다.
  . 도메인(고수준) 계층에서 인터페이스를 정의하고, 인프라스트럭처(저수준)에서 해당 인터페이스를 구현한다.
  . 도메인은 인터페이스를 통해서 인프라스트럭처 계층에 접근이 가능해지고, DB와 같은 구현기술이 변경되어도 코드 변경이 불필요해진다.
  (구현기술이 변경되면 인프라스트럭처에서 해당 인터페이스를 다시 구현하면 됨)

---

DIP 사용시 주의 사항

• 코드 분리가 목적이 아님
  . 단순히 인터페이스를 정의하고, 인프라스트럭처에서 클래스를 구현한 방식이라고 생각하면 안됨
  . 인터페이스가 구현기술(저수준)에 의존적이면 안됨, 인터페이스는 도메인(고수준) 영역에서 정의되야함
  . 인터페이스가 구현기술에 의존적이면, 구현기술이 변경되면 또다른 인터페이스를 구현해야하는 일이 발생할 수 있음

---

도메인 영역의 주요 구성요소

• Entity
  . 고유의 식별자를 갖는 객체
  . 스스로 LifeCycle을 갖는다.
  . 도메인의 고유한 개념을 표현(주문, 배송, 제품, 회원 등)
  . 도메인 모델의 데이터를 포함하며 데이터에 관련된 기능까지 포함(DB의 Entity와의 가장 큰 차이)
• Value
  . 고유의 식별자를 갖지 않는 객체
  . 도메인 객체의 속성을 표현(배송지주소를 표현하기 위한 주소, 주문금액을 표현하기 위한 금액 등)
• Aggregate
  . 관련있는 엔티티와 밸류를 개념적으로 묶은 집합,단위
  . 주문(엔티티) + 주문목록(밸류) + 주문자(밸류) = 주문(애그리거트)
• Repository
  . 도메인 모델의 영속성 처리
• Domain Service
  . 특정 엔티티에 포함되지 않은 도메인 로직을 제공(?)
  . 쿠폰, 회원등급, 구매금액 등의 조건을 이용하여 할인금액을 계산하는 로직과 같이
  여러 엔티티와 밸류를 조합해야 하는 경우 도메인 서비스에서 로직을 구현한다.

---

Aggregate

• 관련있는 데이터(엔티티, 밸류)의 집합체이므로 그 중에서 나머지 요소들을 관리하는 루트 엔티티가 존재한다.
  . 주문 애그리거트는 주문 + 주문목록 + 주문자 + 배송지정보 등과 같이 여러 요소들의 집합으로 구성되고,
  이 중에서 주문 엔티티가 나머지 요소들을 관리할 수 있는 루트 엔티티가 된다.(핵심 객체)
  . 루트 엔티티는 해당 애그리거트가 구현할 기능을 제공할 수 있어야 한다. (주문하기, 주문취소하기, 배송지정보 수정하기 등등)
  . 루트 엔티티를 통하지 않고 세부 요소들로 접근하지 못하도록 인터페이스를 구현해야 한다. (무결성 보장)

---

Http 요청 처리 흐름

---

모듈 구성

• ui(controller)
• application(service)
• domain
  . 도메인의 크기가 커지면 하위 도메인별로 나눈다. (주문, 회원, 제품 등으로 분리)
  . ex) ~.domain.order: 애그리거트, ~.domain.service: 도메인 서비스
• infrastructure

---

재밌긴한데 책만 보니까 사실 감이 잘 안오는 면도 있다.
내일부턴 직접 설계를 시작해보면서 조금씩 그려나가봐야겠다.
Ch4장부터 난이도가 많이 높아졌다는 느낌이 들다가 Ch5장은 읽다가 접었다.

(실제로 구현해보고 부딪쳐야 이해갈거같음)

아직 문서작성을 어떻게 해야하는지 잘모르겠는데 mermaid를 티스토리에서 지원이안되나? 조금 불편한거같다..