표현 영역
- HTTP 요청을 응용 영역이 필요로 하는 형식으로 변환해서 응용 영역에 전달하고 응용 영역의 응답을 HTTP 응답으로 변환하여 전송한다.
응용 영역
- 로직을 직접 수행하기 보다는 도메인 모델에 로직 수행을 위임한다.
도메인 영역
- 도메인 모델을 구현한다. 즉, 도메인의 핵심 로직을 구현한다.
ex) 배송지 변경, 결제완료 등
인프라스트럭쳐 영역
- 논리적인 개념을 표현하기보다는 실제 구현 기술에 대한 것을 다룬다. ex) 메시징 큐, DB
계층 구조는 그 특성상 상위 게층에서 하위 계층으로의 의존만 존재하고 하위 계층은 상위 계층에 의존하지 않는다.
표현 -> 응용 -> 도메인 -> 인프라스트럭쳐
상위 계층이 하위 계층에 의존을 하게 되면 하위 계층 변화에 상위 계층이 영향을 받게 되는 문제가 발생한다.
ex) 테스트의 어려움, 기능 확작의 어려움
DIP를 사용한다면 위와같은 문제를 해결할 수 있음
저수준 모듈이 추상화한 인터페이스를 사용해서 고수준 모듈에 의존하도록 하여 의존성을 하위 모듈 방향이 아닌 상위 모듈로 역전시키는 방법
상위 계층에서는 추상화한 인터페이스를 의존하고 있기 때문에 하위 계층이 변경이 되더라도 문제가 없거나 약간의 변화만 발생하며 테스트하기 쉽고 변경에 유연해진다.
인프라스트럭처 영역은 구현 기술을 다루는 저수준 모듈이고 응용 역영과 도메인 영역은 고수준 모듈이다. 인프라스트럭처 계층의 가장 하단에 위치하는 계층형 구조와 달리 아키텍처에 DIP를 적용하면 아래 그림과 같이 인프라스트럭처 영역이 응용 영역과 도메인 영역에 의존(상속)하는 구조가 된다
- 궁금증 🙄
대부분 서비스에대한 인터페이스를 설계할때 해당 서비스가 변경가능성이 없어보여도 느슨한 결합과 혹시 모르는 변경가능성으로 인해 인터페이스를 설계하라고 한다.. 책과 반대되는 내용 아닐까..?
요소 | 설명 |
---|---|
엔티티 | 고유의 식별자를 갖는 객체로 자신의 라이프사이클을 갖는다. 도메인의 고유한 개념을 표현하며 해당 데이터와 관련된 기능을 함께 제공한다. |
밸류 | 고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 도메인 객체의 속성을 표현할 때 사용된다. |
애그리거트 | 애그리거트는 관련된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 '주문' 애그리거트로 묶을 수 있다. |
리포지터리 | 도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다. |
도메인 서비스 | 특정 엔티티에 속하지 않은 도메인 로직을 제공한다. '할인 금액 계산'은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 할 경우 도메인 서비스에서 로직을 구현한다. |
도메인이 커질수록 개발할 도메인 모델도 커지면서 많은 엔티티와 밸류가 출현한다. 엔티티와 밸류 개수가 많아지면 많아질수록 모델은 점점 더 복잡해지는데 이때 도메인모델에서 전체 구조를 이해하는데 도움이 되는 것이 애그리거트
ex) 주문 : 주문,배송지정보,주문자,주문 목록, 총 결제금액
엔티티나 밸류가 요구사항에서 도출되는 도메인 모듈이라면 리포지터리는 구현을 위한 도메인 모델
응용 서비스와 리포지터리는 밀접한 연관이 있음
- 응용 서비스는 필요한 도메인 객체를 구하거나 저장할 때 리포지터리를 사용한다.
- 응용 서비스는 트랜잭션을 관리하는데, 트랜잭션 처리는 리포지터리 구현 기술에 영향을 받는다.