DDD 2. 아키텍쳐 개요

⌜아키텍쳐 개요⌟

1. 네 개의 영역

• 표현

• 응용

• 도메인

• 인프라스트럭쳐

2. 계층 구조 아키텍쳐

표현 -> 응용 (고수준 모듈) -> 도메인 (고수준 모듈) -> 인프라스트럭쳐 (저수준 모듈)

• 계층 구조는 그 특성상 상위 계층에서 하위 계층으로의 의존만 존재하고 하위 계층은 상위 계층에 의존하지 않는다.
• 하지만 표현, 응용, 도메인 계층은 상세한 구현 기술을 다루는 인프라스트럭쳐 계층에 종속되는 것이 문제가 된다.
• 따라서 테스트의 어려움과 기능 확장의 어려움이라는 두 가지 문제가 발생하게 된다.
• 이러한 문제를 해결하기위해 DIP 를 적용하게 된다.

3. DIP (Dependency Inversion Principle)

DIP : 저수준 모듈이 고수준 모듈에 의존하는 개념 (의존 역전 원칙)

• DIP 를 적용하면 다른 영역이 인프라스트럭쳐 영역에 의존할 때 발생했던 두 가지 문제인 구현 교체의 어려움과 테스트의 어려움을 해소할 수 있다.
  1. 저수준 모듈의 기능을 추상화해서 고수준 모듈을 만들고 해당 모듈을 인프라 영역에서 도메인 영역으로 위치시킨다.
  2. 따라서 단순히 저수준 모듈의 기능을 추상화 한 것에서 끝나는 것이 아니라 인프라스트럭쳐 영역이 응용 영역과 도메인 영역에 의존하는 구조가 된다.
  3. 하지만 DIP를 항상 적용할 필요는 없다. 무조건 DIP를 적용하려고 시도하지 말고 DIP의 이점을 얻는 수준에서 적용범위를 검토해도 충분하다.

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

• 요소

  • 엔티티(Entity)

    고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. ( 관련 테이블이 여러개가 될 수 있다. 다만 주 테이블 외의 다른 테이블은 밸류의 개념을 갖는다. ) 주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.

  • 밸류(Value)

    고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 값을 표현할 때 사용된다. 배송지 주소를 표현하기 위한 주소나 구매 금액을 위한 금액과 같은 타입이 밸류 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다.

  • 애그리거트(Aggregate)

    애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 ‘주문’ 애그리거트로 묶을 수 있다.

  • 리포지토리(repository)

    도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다.

  • 도메인 서비스(Domain Service)

    특정 엔티티에 속하지 않은 도메인 로직을 제공한다. ’할인 금액 계산’은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

5. 모듈 구성

• 도메인
  • 하위 도메인
    • 표현
    • 응용
    • 도메인(애그리거트 기준)
    • 인프라스트럭쳐