유스케이스, 웹 어댑터, 영속성 어댑터는 구현했으니 동작하는 애플리케이션으로 조립해야 한다. 애플리케이션이 시작될 때 클래스를 인스턴스화하고 묶기 위해 의존성 주입 메커니즘을 이용한다.
유스케이스와 어댑터를 그냥 필요할 때 인스턴스화하면 안 되는 이유는 코드 의존성이 올바른 방향을 가리키게 하기 위해서다. 모든 의존성은 안쪽으로, 애플리케이션의 도메인 코드 방향으로 향해야 도메인 코드가 바깥 계층의 변경으로부터 안전하다는 점을 기억하자.
만약 유스케이스가 영속성 어댑터를 호출해야 하고 스스로 인스턴스화한다면 코드 의존성이 잘못된 방향으로 만들어진 것이다. 이게 바로 아웃고잉 포트 인터페이스를 생성한 이유다. 유스케이스는 인터페이스만 알아야 하고, 런타임에 이 인터페이스의 구현을 제공 받아야 한다.
이 프로그래밍 스타일의 유익한 부수효과 중 하나는 코드를 훨씬 더 테스트하기 쉽다는 것이다. 한 클래스가 필요로 하는 모든 객체를 생성자로 전달할 수 있다면 실제 객체 대신 목으로 전달할 수 있고, 이러면 격리된 단위 테스트를 생성하기 쉬워진다.
중립적인 설정 컴포넌트는 인스턴스 생성을 위해 모든 클래스에 접근할 수 있다.
그림처럼 아키텍처에 대해 중립적이고 인스턴스 생성을 위해 모든 클래스에 대한 의존성을 가지는 설정 컴포넌트가 있어야 한다는 것이다.
클린 아키텍처에서 이 설정 컴포넌트는 의존성 규칙에 정의된 대로 모든 내부 계층에 접근할 수 있는 원의 가장 바깥쪽에 위치한다.
설정 컴포넌트는 우리가 제공한 조각들로 애플리케이션을 조립하는 것을 책임진다.
추가로 설정 컴포넌트는 설정 파일이나 커맨드라인 파라미터 등과 같은 설정 파라미터의 소스에도 접근할 수 있어야 한다. 애플리케이션이 조립되는 동안 설정 컴포넌트는 이런 파라미터를 애플리케이션 컴포넌트에 제공해서 어떤 DB에 접근하고 어떤 서버를 메일 전송에 사용할지 등의 행동 양식을 제어한다.
책임이 굉장히 많다. 단일 책임 원칙을 위반하지만 애플리케이션의 나머지 부분을 깔끔하게 유지하고 싶다면 구성요소들을 연경하는 바깥쪽 컴포넌트가 필요하다. 그리고 이 컴포넌트는, 작동하는 애플리케이션으로 조립하기 위해 애플리케이션을 구성하는 모든 움직이는 부품을 알아야 한다.