CH02 의존성 역전하기

클린 아키텍처의 핵심 DIP

클린 아키텍처에서 비즈니스 규칙을 다루는 도메인은 기술(프레임워크, 데이터베이스 등)로부터 완벽하게 격리되어 자유롭게 존재한다.

이 말을 다르게 하자면 의존 방향이 도메인에서 바깥으로 나갈 일이 없다는 것이다.

위 그림은 너무나 많이 사용되는 그림인데 의존 방향을 잘 보자. 밖에서 안으로 들어가지 안에서 밖으로 가진 않는다. 이것은 결국 DIP 덕분에 가능한 것이다.

DIP는 다른 곳에서도 많이 정리를 해서 자세히 다루는 것은 생략한다. 핵심만 간단히 언급하자면 usecase -> infrastructure 가 되어야 데이터베이스를 쓰든 어쩌든 할 텐데 이러면 결국 기술에 의존하는 형태가 되어버리니까 usecase 내에 동일한 계층으로 인터페이스를 구현하고 usecase -> usecase (동일 계층 내에서 인터페이스에 의존하고 여기 주입이 뭐가되든 상관없고 알 수도 없고 알 필요도 없음) 형태로 구현한 뒤 usecase <- infrastructure 로 의존 방향을 역전시키는 것이다.

아래 그림은 책에서 설명하는 DIP 예시이다.

도메인 내에 인터페이스를 구현하고 기대하는 기능을 선언한 뒤 영속성에서 이 인터페이스에 의존하도록 함으로써 의존의 방향을 도메인 -> 영속성 에서 도메인 <- 영속성 으로 역전 시킨 것을 알 수 있다.

그래서 DIP 를 적용 함으로써 의존 방향이 내부로만 가게 한 것은 알겠는데, 이게 어떤 효과가 있다는 걸까?

핵심 비즈니스 로직을 다루는 도메인을 기술로부터 완전히 격리 시킴으로써 철저하게 도메인은 비즈니스 규칙에만 집중 할 수 있다. POJO 객체만으로 시스템의 비즈니스 로직을 제어할 수 있게 된다.

JPA 가 적용된 계층형 아키텍처에서 비즈니스 로직을 다루는 @Entity 가 쓸데없이 기본 생성자 등을 가져야 했던 것을 생각하면 핵심 비즈니스 로직에도 신경쓰면서 기술에도 인볼브 되어 있는 상태인 것이다. 이를 생각해보면 헥사고날 아키텍처에서는 DIP 를 적용해서 깔끔하게 기술로부터 도메인을 격리시키고 도메인은 도메인에만 집중할 수 있게 한다.

유스케이스 덕분에 넓은 서비스를 피할 수 있다

위 구조도에서도 볼 수 있듯이 유스케이스가 도메인에 접근을 하는데 유스케이스로 시스템의 기능을 구조적으로 분리함으로써 기존에 계층형 아키텍처에서 다뤘던 넓은 서비스를 피할 수 있고, 그만큼 시스템 구조 자체가 더 가시적이다.

육각형 아키텍처 도식

나는 개인적으로 저 동그라미 도식보다 위 도식이 훨씬 코드와 생긴 갭이 적어서(거의 없다고 봐도 될 정도로 도식이 구조를 잘 드러내주어서) 이 그림을 더 선호한다.

여기서 디테일하게 구현의 방향을 잘 봐야한다. 유스케이스는 결코 어댑터를 의존하지 않는다.