Chapter 2 아키텍처 개요

2.1 네 개의 영역

• 표현 영역
  • Controller 부분
  • 사용자와 상호 작용하는 영역
  • HTTP 요청 ↔ 응용 영역이 서로 통신할 수 있도록 요청과 응답을 변환
• 응용 영역
  • Service 부분
  • 시스템이 사용자에게 제공해야 할 기능을 구현
  • 기능을 구현하기 위해 도메인 영역의 도메인 모델을 사용
• 도메인 영역
  • Entity, Value 부분
  • 도메인의 핵심 로직을 구현
    • ex) Order 도메인의 핵심 기능은 ‘배송지 변경’, ‘결제 완료’ … 등이 있으며 해당 로직을 구현한다.
• 인프라스트럭처 영역
  • Repository, Utils 부분
  • 도메인 로직을 지원하고 구현을 외부 시스템과 연결하는 기술적 구조
    • ex) DB 연결, STMP 메일발송, 메세지큐 … 등

2.2 계층 구조 아키텍처

• 상위 계층에서 하위 계층으로 의존만 존재하고 하위 계층에서 상위 계층에 의존하지 않는다.

2.3 DIP

• DIP 란?
  • DIP(Dependency Inversion Principle, 의존성 역전 원칙)은 객체 지향 설계 원칙 중 하나로, 고수준 모듈이 저수준 모듈에 의존해서는 안 되고, 추상화를 통해 저수준 모듈이 고수준 모듈을 의존
• 장점
  • 저수준 모듈을 교체 하기가 용이
  • 테스트코드를 구현하기에 용이
    • 저수준 모듈의 구현체가 없는 추상화(Interface)만 존재하는 경우에도 테스트 코드 작성이 가능하다 (Mock 이용)

2.3.1 DIP 주의사항

• 단순히 인터페이스와 구현 클래스를 분리하는 것은 잘못된 사용
• 결과 구조만 보는것이 아닌 모듈의 관점에서 생각하여 추상화를 만들어야 한다.
  • ex)
    1. cacluateDiscountService → RuleEngine ← DroolsRuleEngine (잘못된 사용)
    2. cacluateDiscountService → RuleDiscounter ← DroolsRuleDiscounter (good)

2.3.2 DIP와 아키텍처

• DIP를 적용하게 되면, 응용 영역과 도메인 영역의 코드 수정 없이 인프라스트럭처부분만 코드를 추가/수정 및 변경하여 요구사항을 충족시킬 수 있다.

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

구성요소	설명	예시
엔티티(Entity)	고유 식별자를 가지며, 상태와 동작을 포함하는 객체	User, Order, Product
값 객체(Value Object)	고유 식별자가 없으며, 불변 객체로 주로 여러 속성을 하나의 개념으로 묶을 때 사용	Address, Money, DateRange
애그리게잇(Aggregate)	관련된 엔티티와 값 객체의 그룹으로, 일관된 변경을 보장하기 위한 경계를 정의하고 루트 엔티티를 통해 접근	Order (루트: Order, 구성 요소: OrderLine)
리포지토리(Repository)	애그리게잇을 영구 저장소에서 조회하고 저장하는 메커니즘을 제공, 인터페이스와 구현체로 구성	OrderRepository, UserRepository
도메인 서비스(Domain Service)	특정 엔티티에 속하지 않는 도메인 로직을 캡슐화하는 서비스	PricingService, PaymentService

2.4.1 엔티티와 벨류

• 도메인 모델의 엔티티 vs DB 테이블의 엔티티
  • 도메인 모델의 엔티티는 단순 데이터만 담고 있는 구조가 아닌 데이터와 함께 도메인 기능을 제공
  • 도메인 모델 두개이상의 데이터가 개념적으로 하나인 경우에 Value 타입을 이용해서 표현할 수 있다.
    • ex) Order → name, email 을 Orderer라는 Value타입 객채를 만들어 관리 가능

2.4.2 애그리거트

• 지도를 볼 때 매우 상세하게 나온 대축척 지도를 보면 큰 수준에서 어디에 위치하고 있는지 이해하기 어려우므로 큰 수준에서 보여주는 소축척 지도를 함께 봐야 현재 위치를 보다 정확하게 이해할 수 있다. 이와 비슷하게 도메인 모델도 개별 객체뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는데 도움이 된다.
  • ex) ‘주문’, ‘배송지 정보’, ‘주문자’, ‘주문 목록’, ‘총 결제 금액’의 하위 모델들을 ‘주문’이라는 상위 개념으로 표현할 수 있다.

2.5 요청 처리 흐름

2.6 인프라스트럭처 개요

• 표현 영역, 응용 영역, 도메인 영역을 지원한다.
• DIP에서 언급한 내용처럼 인프라스트럭처의 기능을 직접 사용하는것보다 인터페이스를 만들어서 사용하게 되면 시스템을 더 유연하고 테스트하기 쉽게 만들어준다. 하지만 무조건 인프라스트럭처에 대한 의존을 없애게 되면 오히려 더 복잡하고 어려운 코드를 유도할 수 있다.
  • ex) 인프라 스트럭처를 직접 사용하지 않기 위해 @Transaction 어노테이션을 사용하지 않고 개발을 하려고 하면 한줄로 처리할 수 있는 코드를 복잡하고 개발시간만 더 늘어날 뿐이다.

2.7 모듈 구성

• 도메인이 크면 하위 도메인으로 나누고 각 하위 도메인 마다 별도 패키지를 구성한다.
• 모듈 구성에 대해서는 정답이 없으며, 한 패키지에 10~15개 미만으로 타입 개수를 유지하려고 노력한다.