[DDD-START] Ch02. 아키텍쳐 개요
in Dev-Study on Architecture
공부하는 내용을 정리하는 목적으로 작성하고 있습니다. 잘못 작성된 내용을 지적해주시면 좀더깊이 공부해서 내용을 수정하겠습니다.
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장은 읽다가 접었다.
(실제로 구현해보고 부딪쳐야 이해갈거같음)
DDD-START (최범균님 저) 도서 참조