코드 구성하기

계층으로 구성하기

 

계층으로 코드를 구성하면 기능적인 측면들이 섞이기 쉽다.

문제점

1. 어플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없다.
   추가적인 구조가 없다면, 아주 빠르게 서로 연관되지 않는 기능들끼리 예상하지 못한 부수효과를 일으킬 수 있는 클래스들의 묶음으로 변모할 가능성이 크다
2. 어플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다.
   특정 기능을 찾기 위해서는 어떤 서비스가 이를 구현했는지 추측해야 하고, 해당 서비스 내의 어떤 메서드가 그에 대한 책임을 수행하는 지 찾아야한다.

기능으로 구성하기

기능을 기준으로 코드를 구성하면 기반 아키텍처가 명확하게 보이지 않는다.

장점

1. 패키지 경계를 package-private 접근 수준과 결합하면 각 기능 사이의 불필요한 의존성을 방지할 수 있다.
2. AccountService -> SendMoneyService로 책임이 좁혀졌다. 구현한 코드는 클래스명만으로도 찾을 수 있게 됐다.

단점

1. 기능에 의한 패키징 방식은 계층에 의한 패키징 방식보다 아키텍처 가시성을 훨씬 더 떨어뜨린다.
2. package-private 접근 수준을 이용해 도메인 코드가 실수로 영속성 코드에 의존하는 것을 막을 수 없다.

아키텍처적으로 표현력 있는 패키지 구조

육각형 아키텍처에서 구조적으로 핵심적인 요소는 엔티티, 유스케이스, 인커밍/아웃고잉 포트, 인커밍/아웃고잉 어댑터다

 

domain 패키지는 헥사고날에서 정중앙에 위치하고 그걸 감싸는 application 패키지가 존재한다 그리고 adapter 패키지를 통해서 application 패키지 내에 있는  port 패키지와 소통한다.

이 패키지 구조는 아키텍처-코드 갭 또는 모델-코드 갭을 효과적으로 다룰 수 있는 강력한 요소다.

여기서 패키지가 많다고 모든 패키지를 public으로 접근제어자를 허용할 필요 없다 adapter와의 소통은 오직 port로만 하여 나머지는 private-package로 사용할 수 있다.

하지만 application, domain 패키지 내의 일부 클래스들은 public으로 지정해야하는 단점이 있다.

의존성 주입의 역할

웹 컨트롤러가 서비스에 의해 구현된 인커밍 포트를 호출한다.
서비스는 어댑터에 의해 구현된 아웃고잉 포트를 호출한다

어플리케이션 계층에 어댑터에 대한 의존성을 추가하고 싶지는 않기 때문에

이부분에서 의존성 주입을 활용할 수 있다.

모든 계층에 의존성을 가진 중립적인 컴포넌트를 하나 도입한다.

이 컴포넌트는 아키텍처를 구성하는 대부분의 클래스를 초기화하는 역할을 한다.