CHAPTER 2. 아키텍처 개요

1. 네 개의 영역

• 아키텍처를 설계할 때 출연하는 '표현' , '응용' , '도메인' , '인프라스트럭처'의 네 영역이다.
• 표현 영역을 통해 사용자의 요청을 전달받은 응용영역은 시스템이 사용자에게 제공해야 할 기능을 구현한다.응용서비스는 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.
• 도메인 영역은 도메인 모델을 구현한다. 도메인 모델은 도메인의 핵심 로직을 구현한다. 주문 도메인의 경우 배송지변경, 결제완료 등과 같은 핵심 로직을 도메인에서 구현한다.

2. 계층 구조 아키텍처

• 계층 구조는 상위 계층에서 하위 계층으로의 의존만 존재하고 하위 계층은 상위 계층에 의존하지 않는다.
• 도메인과 응용 계층은 룰 엔진과 DB연동을 위해 위와 같이 인프라스트럭쳐 모듈에 의존하게 된다.
• 도메인이 인프라에 종속적이게 되면 도메인으로써의 테스트가 어려워진다.
• 인프라를 통해서 받아오는 데이터를 기준으로 처리하게 되면 인프라와 관련된 부분이 변경되거나 추가될 경우 부가적인 어려움이 발생하게 된다. 이를 해결 하기 위해서 DIP가 있다.

3. DIP

• 고객정보를 구하고, 룰을 이용해서 할인 금액을 구하는 로직은 인프라에 종속적인 내용으로, 구현의 변경과 테스트에 어려움이 발생한다.
• 저수준 모듈이 고수준 모듈에 의존하도록 구조를 바꾸기 위해 추상화한 인터페이스를 통해 문제를 해결할 수 있다.

Public interface RuleDiscounter {
	public Money applyRules(Customer customer, List<OrderLine> orderLines);
}

• 저수준 모델들이 interface를 바라보게, 저수준 모델이 고수준 모델에 의존하여 기능을 구현할 수 있도록 개선한다.

• 인프라스트럭처 영역은 구현 기술을 다루는 저수준 모듈이고, 응용 영역과 도메인 영역은 고수준 모듈이다.
• DIP를 적용하면 응용 영역과 도메인 영역에 영향을 최소화 하면서 구현체를 변경 및 추가할 수 있다.

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

엔티티(Entity)

고유의 식별자를 갖는 객체로 자신의 라이프사이클을 갖는다. 주문,상품,회원과 같이 도메인의 고유한 개념을 표현한다.(Order, Member, Product)

밸류(Value)

고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나의 도메인 객체의 속성을 표현할 때 사용된다. (Address, Money)

애그리거트(Aggregate)

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

리포지토리(Repository)

도메인 모델의 영속성을 처리한다.
도메인 서비스(Domain Service)
특정 엔티티에 속하지 않은 도메인 로직을 제공한다.

5. 인프라스트럭처 개요

• 인프라스트럭쳐는 표현영역, 응용영역, 도메인 영역을 지원한다.
• DIP에서 언급한 것처럼 도메인 영역고 응용영역에서 인프라스트럭처의 기능을 직접 사용하는것보다, 이 두 영역에 정의한 인터페이스를 인프라스트럭처 영역에서 구현하는 것이 시스템을 더 유연하고 테스트하기 쉽게 만들어 준다.

6. 모듈 구성

• domain 모듈은 도메인에 속한 애그리거트를 기준으로 패키지를 구성한다.
• 모듈 구조를 얼마나 세분화해야 하는지에 대해 정해진 규칙은 없다.
• 단지, 한 패키지에 너무 많은 타입이 몰려서 코드를 찾을 때 불편한 정도만 아니면 된다고 한다.
• 한 패키지에 10개 미만의 타입개수를 유지하려고 노력한다.