3장 - 코드 구성하기

계층으로 구성하기

웹, 도메인, 영속성 계층으로 패키지를 나눈 모습입니다.

DIP를 통해 domain 패키지에 있는 코드만을 가리키도록 했습니다.

 

하지만 애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없습니다.

관리자 기능을 추가하기 위해서는 web 패키지에 UserController를 추가하고 domain 패키지에 UserService, UserRepository, User를 추가하고, persistence 패키지에 UserRepositoryImpl을 추가해야 합니다.

 

이렇게 되면 서로 연관되지 않은 기능들끼리 예상하지 못한 부수효과를 일으킬 수 있게 됩니다.

 

또한 특정 기능을 찾기 위해 어떤 서비스가 이를 구현했는지 추측하고, 해당 서비스 내의 어떤 메서드가 그에 대한 책임을 수행하는지 찾아야 합니다.

 

어떤 기능이 웹 어댑터에서 호출되는지, 영속성 어댑터가 도메인 계층에 어떤 기능을 제공하는지 한눈에 알아볼 수 없게 됩니다.

 

기능으로 구성하기

 

이제 송금하기 유스케이스를 구현한 코드는 클래스명만으로도 찾을 수 있게 됩니다.

이를 로버트 마틴은 '소리치는 아키텍처'라고 명명한 바 있습니다.

(코드가 그 의돌르 우리에게 소리치고 있기 때문)

 

하지만 아키텍처의 가시성은 훨씬 더 떨어집니다.

어뎁터를 나타내는 패키지명이 없고, 인커밍 포트, 아웃고잉 포트를 확인할 수 없습니다.

 

package-private 접근 수준을 이용해 도메인 코드가 실수로 영속성 코드에 의존하는 것을 막을 수 없습니다.

 

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

구조의 각 요소들은 패키지 하나씩에 직접 매핑됩니다.

이처럼 표현력 있는 패키지 구조는 아키텍처에 대한 적극적인 사고를 촉진합니다.

 

패키지가 많다는것은 public으로 패키지 간의 접근을 허용한다는 것을 의미할까요?

 

어댑터 패키지 내에 있는 모든 클래스들은 인터페이스를 통하지 않고는 바깥에서 호출되지 않기 때문에 package-private 접근 수준으로 두어도 됩니다.

 

하지만 application 패키지와 domain 패키지 내의 일부 클래스들은 public으로 지정해야 합니다.

의도적으로 어댑터에서 접근 가능해야 하는 포트들은 public이어야 합니다.

 

도메인 클래스들은 서비스, 그리고 잠재적으로 어뎁터에서 접근 가능하도록 public이어야 합니다.

 

이 패키지 구조의 장점으로는 하나의 어뎁터를 다른 구현으로 쉽게 교체할 수 있습니다.

 

또 다른 매력적인 장점으로는 DDD 개념에 직접적으로 대응시킬 수 있습니다.

account와 같은 상위 레벨 패키지는 다른 바운디드 컨텍스트와 통신할 전용 진입점과 출구에 해당합니다.

domain 패키지 내에서는 DDD가 제공하는 모든 도구를 이용해 우리가 원하는 어떤 도메인 모델이든 만들 수 있습니다.

 

의존성 주입의 역할

패키지 구조가 클린 아키텍처에 도움이 되지만 가장 본질은 애플리케이션 계층이 인커밍/아웃고잉 어댑터에 의존성을 갖지 않는 것입니다.

 

 

모든 계층에 의존성을 가진 중립적인 컴포넌트를 하나 도입하여 해당 컴포넌트에 아키텍처를 구성하는 대부분의 클래스를 초기화하는 역할을 수행하게 할 수 있습니다.

 

이렇게 되면 Controller가 SendMoenyUseCase 인터페이스를 필요로 하기 때문에 의존성 주입을 통해 SendMoneyService를 주입합니다.

 

컨트롤러는 인터페이스만 알면 되기 때문에 자신이 SendMoneyService 인스턴스를 실제로 가지고 있는지도 모릅니다.