2장 아키텍처 개요

2.1 네 개의 영역

표현, 응용, 도메인, 인프라스트럭처는 아키텍처를 설계할 때 출현하는 전형적인 네 가지 영역이다. -p.62

• 솔직히 항상 계층형 아키텍처를 떠올릴때
• 표현/응용/영속성 + 인프라스트럭처,혹은 구현 레벨에서
• 컨트롤러/서비스/리포지토리 + 인프라스트럭처(설정 등)
• 으로 세가지 계층 + 인프라 영역 으로 나누어 생각했기 때문에

• 도메인을 하나의 계층으로 표현하고 인프라를 가장 하단에 표현한 이책의 네 가지 영역의 계층형 아키텍처가 익숙하게 느껴지지 않았다.

• 링크 오션 프로젝트 초기에 고려했던 Facade 패턴과 관련이 깊어 보인다.

2.2 계층 구조 아키텍처

도메인의 복잡도에 따라 응용과 도메인을 분리하기도 하고 한 계층으로 합치기도 하지만 전체적인 아키텍처는 [그림 2.4]의 계층 구조를 따른다. -p.65

• 테스트 어려움

• 기능 확장의 어려움

• 네이버 D2의 ArchUnit 아키텍처 검사 규칙을 잘 못 이해해서 프로젝트에 잘못된 의존성 룰을 도입한것 같다. Support 패키지와 Infrastructure 계층을 착각해서 Domain → Infrastructure 계층의 접근이 가능하고 그 역방향 접근을 막아야 되는 것으로 이해 해버렸다. 바꾸어야 겠다.

반대가 되어야 함!!!!

2.3 DIP

• 이를 통해 의존성의 방향을 응용 계층으로 집중 시킬 수 있다.

• 응용 계층이 인프라스트럭처를 사용하지만 의존 성의 방향은 반대로!

• 자꾸 보니까 링크 오션에 application 계층을 도입하고 싶어진다…
• 응용 서비스와 domain 서비스를 구분하는 것이 안되었던 것 같다.

DIP를 항상 적용할 필요는 없다. -p.79

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

엔티티와 밸류

• 엔티티와 DB 테이블의 차이
• 엔티티는 데이터와 함께 도메인 기능을 함께 제공한다.
• 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용해 표현할 수 있다.

애그리거트

• 관련 객체를 묶어서 객체 군집 단위로 모델을 바라볼 수 있게 된다.

• 큰 틀에서 도메인 모델을 관리할 수 있다.

리포지토리

• 경험상 구현의 용이성을 위해 DIP의 가치를 가장많이 희생하는 구성 요소 중 하나 이다

• 구현을 위한 도메인 모델

• 도메인 영역의 구성 요소에 대한 이해가 부족할 때 엔티티와 리포지토리가 같은 패키지에 있는 것을 보고 이상하다고 느낀적이 많은데 책의 내용을 보니 좋은 구성같다.

 

• 그렇지만 아직 도메인 패키지에 리포지토리의 인터페이스가 존재하고 구현체를 DIP 를 적용한 인프라스트럭쳐의 계층으로 표현하는 것이 익숙하게 느껴지지는 않는다.

 

2.5 요청 처리 흐름

2.6 인프라스트럭처 개요

무조건 인프라 스트럭처에 대한 의존을 없앨 필요는 없다. @Transactional 을 이용한 트랜잭션 처리 @Entity, @Table 과 같은 JPA 전용 어노테이션 등을 없애는것은 구현을 매우 어렵게 만든다. 구현의 편리함은 DIP가 주는 다른 장점 만큼 중요하다. - p.92

2.7 모듈 구성

모듈/패키지를 나누는 방식에 정답은 없다. 한 패키지에 가능하면 10~15개 미만으로 타입을 유지하려고 노력한다. - p.96