[도메인 주도 개발 시작하기] 2. 아키텍처 개요

hyng·2023년 1월 19일
0

도메인 주도 개발 시작하기을 읽고 인상 깊었던 내용을 간단히 정리합니다.

계층구조 아키텍처

표현 → 응용 → 도메인 → 인프라스트럭처

  • 계층 구조는 그 특성상 상위 계층에서 하위 계층으로의 의존만 존재하고 하위 계층은 상위 계층에 의존하지 않는다.
  • 여기서 짚고 넘어가야 할 것은 표현, 응용, 도메인 계층이 상세한 구현 기술을 다루는 인프라스트럭처 계층에 종속된다는 점이다.

  • CalculateDiscountService Drools에 간접적인 의존을 갖는다.
    • CalculateDiscountService만 테스트하기 어렵다.
      • RuleEngine 클래스와 관련 설정 파일을 모든 만든 이후에 비로소 CalculateDiscountService를 테스트할 수 있다.
    • 구현방식을 변경하기 어렵다.

→ 인프라스트럭처에 의존하면 “테스트 어려움”과 “기능 확장의 어려움”이라는 두가지 문제가 발생한다.


DIP

고수준 모듈이 제대로 동작하기 위해서는 저수준 모듈을 사용해야 한다. 그런데 고수준 모듈이 저수준 모듈을 사용하면 구현 변경과 테스트가 어렵다는 문제가 발생한다.

→ DIP를 이용해 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다.

DIP의 핵심은 인터페이스와 구현 클래스를 분리하는 게 아니라 고수준 모듈이 저수준 모듈에 의존하지 않도록 하기 위함이다.
DIP를 적용할 때 하위 기능을 추상화한 인터페이스는 고수준 모듈에 위치한다.

  • 가격 할인 계산 - CalculateDiscountService(고수준 모듈) ← 의미 있는 단일 기능 제공
    • 고객 정보 구함 - customerRepository(고수준 모듈) ← 하위 기능을 추상화한 인터페이스
      • JPA 이용해서 고객 정보 구함 - (저수준 모듈) ← 하위 기능을 실제로 구현
    • 룰을 이용해 할인 금액 구함 - RuleDiscounter(고수준 모듈)
      • Drools 이용해서 할인 금액 구함 - (저수준 모듈)

DIP를 적용하면 응용 영역과 도메인 영역에 영향을 최소화하면서 구현체를 변경하거나 추가할 수 있다.


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

도메인 영역의 모델은 도메인의 주요 개념을 표현하며 핵심 로직을 구현한다.

  • 엔티티: 고유의 식별자를 갖는 객체로 주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현한다.
  • 밸류: 고유의 식별자를 갖지 않는 객체로 개념적으로 하나의 값을 표현할 때 사용한다.
  • 애그리거트:
    • 연관된 엔티티와 밸류 객체를 하나로 묶은 것이다. Order엔티티, OrderLine 밸류, Orderer 밸류 객체를 ‘주문’ 애그리거트로 묶을 수 있다.
    • 루트 엔티티는 에그리거트에 속해있는 엔티티와 밸류 객체를 이용해서 에그리거트가 구현해야 할 기능을 제공한다.
  • 리포지토리: 도메인 모델의 영속성을 처리한다.
  • 도메인서비스: 특정 엔티티에 속하지 않은 도메인 로직을 제공한다. 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

요청 처리 흐름

HTTP요청 → Controller(표현) → App Service(응용) → Domain Object(도메인) → Repository(리포지토리)


인프라스트럭처 개요

인프라스트럭처는 표현 영역, 응용 영역, 도메인 영역을 지원한다.

구현의 편리함은 DIP가 주는 다른 장점만큼 중요하기 때문에 DIP의 장점을 해치지 않는 범위에서 응용 영역과 도메인 영역에서 구현 기술에 대한 의존을 가져가는 것이 나쁘지는 않다. (ex. @Table, @Transactional ..)

profile
공부하고 알게 된 내용을 기록하는 블로그

0개의 댓글