DIP

고수준과 저수준

ex) "가격 할인 계산" 서비스
고객정보를 구하고
룰을 이용해 할인 금액을 구한다

• 고객정보를 구하고 ➡️ JPA로 구한다 (저수준)
• 룰을 이용해 할인 금액을 구한다 ➡️ DRools로 룰을 적용한다 (저수준)

저수준 모듈이 고수준 모듈에 의존해야 한다 ➡️ 추상화 한 인터페이스로 구현

"가격 할인 계산" 서비스 에서 고객정보를 구할 때 (고수준) JPA로 구하던지, Rest Call (저수준)로 구하던지 구현 방법은 몰라도 된다.
➡️ 고수준은 저수준을 몰라도 된다

(출처: 김영한님의 '스프링 핵심 원리 기본편')

그림에서

• OrderServiceImpl + DiscountPolicy: 고수준
• FixDiscountPolicy, RateDiscountPolicy: 저수준

실제 구현체는 의존성 주입 코드로 주입받을 수 있다

DIP 적용 시 또다른 이점은, 구현체가 개발되어있지 않아도 대역 객체를 주입하여 테스트를 할 수 있다.

해당 그림에서 Infrastructure Layer가 저수준 모듈이고, Application Layer, Domain Layer는 고수준 모듈이다.

의존하는 구조는 위의 이미지와 반대로, Infrastructure Layer(저수준)이 Application, Domain Layer (고수준)을 의존하게 된다.

무조건 DIP를 적용해야 되나? ➡️ 무작정 DIP를 도입하려고 하지말고, DIP로 구현했을 때의 이점을 충분히 생각하고 도입해보자!

Domain Layer

도메인 영역은 도메인의 핵심 모델을 구현한다

• 도메인 영역의 주요 구성요소: Entity, Value

• Entity와 Value에 대한 자세한 설명은 DDD START (2) 참고

Entity와 Value

DB TB Entity != Domain 모델 Entity

차이점은 무엇일까?
Domain 모델 Entity는 데이터 + 도메인 기능 함께 제공한다

ex)

public class Order {
	private Orderer orderer;
    ...
}

public class Orderer {
	private String name;
    private String email;
}

RDBMS에서의 표현

• Order TB와 Orderer TB 두개로 나뉘어지고, Order TB의 order_no 를 Orderer TB에서 FK로 가지고 있다

Order Domain Entity

• Orderer 개념을 가지고 있어서 Domain을 잘 이해할 수 있도록 돕는다

Aggregate

연관된 Entity, Value 객체를 개념적으로 하나로 묶은 것
도메인 모델에서 전체 구조를 이해하는데 도움이 된다

ex) 주문 Aggregate
Order Entity, OrderLine Value, Orderer Value가 포함된다

Repository

Domain 모델의 영속성 처리. DBMS 에서 엔티티 객체 로딩

Aggregate 단위로 Domain 객체를 저장하고 조회한다

Domain Service

특정 Entity에 속하지 않은 Domain 로직 제공

ex) 할인 금액 계산
상품, 쿠폰, 회원 등급, 구매 금액 등의 Entity 사용