목차
계층으로 구성하기
코드를 구조화하는 첫 번째 접근법은 계층을 이용하는 것으로서, 다음과 같이 코드를 구성할 수 있다.
그러나 적어도 세가지 이유로 이패키지 구조는 최적의 구조가 아니다.
첫 번째로, 애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없다. 사용자를 관리하는 기능을 추가해야 한다면 web 패키지에 UserController를 추가하고, domain 패키지에 UserService, UserRepoistory, User를 추가하고 persistence 패키지에 UserRepostioryImpl을 추가하게 될 것이다. 추가적인 구조가 없다면, 아주 빠르게 서로 연관되지 않은 기능들끼리 예상하지 못한 부수효과를 일으킬 수 있는 클래스들의 엉망진창 묶음으로 변모할 가능 성이크다.
두 번째로, 애플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다. AccountService와 AccountController가 어떤 유스케이스를 구현했는지 파악할 수 있겠는가?
기능으로 구성하기
‘계층으로 구성하기’방법의 몇 가지 문제를 해결해보자.
다음 접근법은 예제 코드를 기능으로 구성한 것이다.
가장 본질적인 변경은 계좌와 관련된 모든 코드를 최상위의 account패키지에 넣었다는 것이다.
장점
각 기능을 묶은 새로운 그룹은 account의 같은 레벨의 새로운 패키지로 들어가고, 패키지 외부에서 접근되면 안 되는 클래스들에 대해 package-private 접근 수준을 이용해 경계를 강화할수 있다.
AccountService의 책임을 좁히기 위해 SendMoneyService로 클래스명을 바꿨다. 이제 ‘송금하기’ 유스케이스를 구현한 코드는 클래스명만으로 찾을 수 있게 됐다.
단점
사실 계층에 의핸 피킨징 방식보다 아키텍처의 가시성을 훨씬 더 떨어뜨린다. 어댑터를 나타내는 패키지명이 없고, 인커밍 포트, 아웃고잉 포트를 확인할 수 없다. 도메인 코드와 영속성 코드 간의 의존성을 역전시켜 SendMoneyService가 AccountRepository 인터페이스만 알고 있고 구현체는 알 수 없도록 했음에도 불구하고, package-private 접근 수준을 이용해 도메인 코드가 실수로 영속성 코드에 의존하는 것을 막을 수 없다.
아키텍처적으로 포현력 있는 패키지 구조
육각형 아키텍처에서 구조적으로 핵심적인 요소는 엔티티, 유스케이스, 인커밍/아웃고잉 포트, 인커밍/아웃고잉 어댑터이다.
이 패키지에 들어 있는 모든 클래스들은 application 패키지 내에 있는 포트 인터페이스를 토하지 않고는 바깥에서 호출되지 않기 때문에 packge-private 접근 수준으로 둬도 된다. 그로므로 애플리케이션 계층에서 어댑터 클래스로 향하는 우발적인 의존성은 있을 수없다.
리뷰
오늘은 클린아키텍처의 패키지의 구조에 대해 알게되었다. 계층형 보다는 아키텍처적으로 표현이 되어 있는 패키지를통해 우발적인 의존성을 제거하고, 좀 더 원활하게 서비스를 찾을 수 있게 구성해야 된다는 것을 알 수 있었다. 좀 더 많은 내용이 있지만 9장과 다음장에서 코드를 통해서 전달한다고하여, 그부분에서 좀 더 자세하게 작성하도록 하겠다.
책 소개 : 만들면서 배우는 클린 아키텍처