CH09 어플리케이션 조립하기

이 챕터에서는 의존성의 방향에 대해서 다시 강조하고 있다.

모든 의존성은 안쪽으로, 어플리케이션의 도메인 코드 방향으로 향해야 도메인 코드가 바깥 계층의 변경으로부터 안전하다는 점을 기억하자.

유스케이스가 영속성 어댑터를 호출해야 하고 스스로 인스턴스화한다면 코드 의존성이 잘못된 방향으로 만들어진 것이다. 이것이 바로 아웃고잉 포트 인터페이스를 생성한 이유다. 유스케이스는 인터페이스만 알아야 하고, 런타임에 이 인터페이스의 구현을 제공 받아야 한다.

유스케이스는 인터페이스만 알아야 한다는 말을 잘 살펴보자. 이 말의 의미는 유스케이스가 '구현체'는 모르고 인터페이스만 안다는 것이다. '구현체가 뭐가 올지는(주입될지는) 모르겠고 나는 포트 명세에만 관심사를 한정 시켜 두겠다'는 의미이다. 유스케이스는 구현체(영속성 어댑터)를 알면 안된다.

그 외에 이 챕터에서 강조하는 내용은 모놀리틱이 아닌 경우를 전제하고 있는거 같긴 한데 멀티 모듈에서 적용될 수 있는 이야기이다. 모듈로 각각 쪼개져 있을때 결국 bean 생성을 어떻게 시킬 것이냐 인데, 이건 멀티 모듈을 설계할 때 자주 마주치는 문제이기도 하고 따로 정리할만큼 전략이 뭔가 대단한게 있는게 아니라서 생략하기로 한다.

배민 포스팅에서는 아래와 같이 각 모듈에 Config 를 두고 이를 api가 import 하는 방식으로 사용했다.

@SpringBootApplication(
    scanBasePackageClasses = [
        CeoUnitedWorkerApplication::class
    ]
)
@Import(value = [AppConfig::class, MongoConfig::class, RetrofitConfig::class, CacheConfig::class, S3Config::class])
@ConfigurationPropertiesScan
class CeoUnitedWorkerApplication
fun main(args: Array<String>) {
    runApplication<CeoUnitedWorkerApplication>(*args)
}

Spring Boot Kotlin Multi Module로 구성해보는 헥사고날 아키텍처 | 우아한형제들 기술블로그우아한형제들 기술블로그 |