왜 조립까지 신경 써야 할까?

• 모든 의존성은 애플리케이션의 도메인 코드 방향으로 향해야 도메인 코드가 바깥 계층의 변경으로부터 안전하다!

• 유스케이스가 영속성 어댑터를 직접 호출하고 스스로 인스턴스화 한다면 의존성 방향이 잘못되게 된다.

  • 이것을 해결하기 위해 우리는 아웃고잉 포트 인터페이스를 도입했다.
  • 유스케이스는 인터페이스만 알아야 하고, 런타임에 이 인터페이스의 구현을 제공받아야 한다.

• 클래스가 필요로 하는 모든 객체를 생성자로 전달한다면 테스트하기 더 용이하다.

  • 실제 객체 대신 Mock으로 전달할 수 있고, 이로 인해 격리된 단위 테스트를 생성하기가 쉬워진다.

• 그러면 결국 누군가 객체 인스턴스를 생성해야할텐데… 누가 책임을 가지게 되는가?

  • ⇒ 설정 컴포넌트

• 설정 컴포넌트 → 아키텍처에 대해 중립적이고 인스턴스 생성을 위해 모든 클래스에 대한 의존성을 가진다.

• 설정 컴포넌트는 클린 아키텍처 구조에서 원의 가장 바깥쪽에 위치!

• 설정 컴포넌트는 애플리케이션을 조립하는 것을 책임진다. (우리가 설정한대로!) 세부적으로는 아래와 같은 역할을 수행한다.

* 웹 어댑터 인스턴스 생성
* HTTP 요청이 실제로 웹 어댑터로 전달되도록 보장
* 유스케이스 인스턴스 생성
* 웹 어댑터에 유스케이스 인스턴스 제공
* 영속성 어댑터 인스턴스 생성
* 유스케이스에 영속성 어댑터 인스턴스 제공
* 영속성 어댑터가 실제로 데이터베이스에 접근할 수 있도록 보장

• 또한 설정 컴포넌트는 설정 파일이나 커맨드라인 파라미터 등과 같은 설정 파라미터의 소스에도 접근 가능해야한다!

• 사실 설정 컴포넌트는 책임이 굉장히 많다. → SRP 위반일까?

  • 맞다. SRP 위반이다. 하지만 애플리케이션의 다른 부분을 깔끔하게 유지하기 위해 이처럼 모든 구성 요소들을 알고 조립해주는 바깥쪽 컴포넌트를 둔 것이다.
  • 즉 Trade-Off라고 볼 수 있겠다.

평범한 코드로 조립하기

• 자바의 main 메서드 안에서 웹 컨트롤러부터 영속성 어댑터까지, 필요한 모든 클래스의 인스턴스를 생성한 후 연결한다. 뿐만 아니라 웹 컨트롤러를 HTTP로 노출시키는 로직도 필요하다.