TIL

09. 애플리케이션 조립하기

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

• 유스케이스가 영속성 어댑터를 호출해야 하고 스스로를 인스턴스화한다면 코드 의존성이 잘못된 방향으로 만들어진 것이다.
  • 유스케이스는 인터페이스만 알아야 한다.
  • 인터페이스 구현체는 런타임에 제공 받아야 한다.
• 아키텍처에 대해 중립적이고 모든 클래스에 대한 의존성을 가진 설정 컴포넌트로 이를 해결할 수 있다.
  • 웹 어댑터 인스턴스 생성
  • HTTP 요청이 실제로 웹 어댑터에 전달되도록 보장
  • 유스케이스 인스턴스 생성
  • 웹 어댑터에 유스케이스 인스턴스 제공
  • 영속성 어댑터 인스턴스 생성
  • 유스케이스에 영속성 어댑터 인스턴스 제공
  • 영속성 어댑터가 실제로 데이터베이스에 접근할 수 있도록 보장
• 설정 컴포넌트는 애플리케이션을 조립하기 위해 애플리케이션을 구성하는 모든 부품을 알아야 한다.

평범한 코드로 조립하기

• 프레임워크 도움 없이 설정 컴포넌트를 직접 구현해서 애플리케이션을 조립할 수 있다.
• 평범한 코드 방식은 몇 가지 단점이 있다.
  • 완전한 엔터프라이즈 애플리케이션을 위한 조립 코드는 너무 많다.
  • 조립되는 각 클래스들은 외부에서 인스턴스를 생성하기에 전부 public이어야 한다. (접근 제한자로 다른 계층으로의 접근을 막을 수 없다.)
• package-private 의존성을 유지하면서 의존성 주입을 해주는 프레임워크가 있기에 직접 조립할 필요는 없다.
  • ex) 스프링

스프링의 클래스패스 스캐닝으로 조립하기

• 스프링은 @Component 애너테이션이 붙은 클래스를 찾아 스프링 빈으로 만들고 빈 간의 의존성을 조립할 수 있다.

• 계층의 역할을 명확히 하기 위해 스프링이 인식할 수 있는 애너테이션을 직접 만들어 사용할 수도 있다.

    @Target({ElementType.TYPE})
    @Retention(RetentionPolicy.RUINTIME)
    @Documented
    @Component
    public @interface PersistenceAdapter {
      	
    	@AliasFor(annotation = Component.class)
    	String value() default "";
    }
  

  • 코드를 읽는 사람이 아키텍처를 더 쉽게 파악할 수 있게 해준다.
• 클래스패스 스캐닝 방식의 단점
  • 클래스에 프레임워크에 특화된 애너테이션을 붙여야 한다. (결합도 증가)
  • 스프링은 특정 부모 패키지를 기준으로 하위에 @Component가 붙은 클래스를 모두 찾아 빈으로 등록하는데 모든 클래스를 파악하는 것도 어렵고 부수 효과로 인한 에러가 발생할 수도 있다.

스프링의 자바 컨피그로 조립하기

• @Configuration 애너테이션이 붙은 설정 클래스 하위에서 @Bean 애너테이션을 통해 클래스들을 빈으로 등록하는 방법
• 이 방식에서는 애플리케이션 계층에서 스프링에 대한 의존성을 없앨 수 있다.
• 자바 컨피그의 단점
  • 설정 클래스가 생성하는 빈이 설정 클래스와 같은 클래스에 존재하지 않는다면 public으로 만들어야 한다.
  • 가시성을 제한하기 위해 각 페키지를 모듈 경계로 사용하고 각 패키지 안에 전용 설정 클래스를 만들 수는 있지만 이렇게 하면 하위 패키지를 사용할 수 없다. (10장에서 설명)