[클린 아키텍처] 의존성 역전하기

단일 책임 원칙

• SRP: 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다.
  • 단일 책임 원칙의 실제 정의는 “컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.”
    • ‘책임’은 ‘변경할 이유’로 해석해야 한다.(Reason to change)

만약 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없다. 여전히 우리가 기대한 대로 동작하기 떄문이다.

단일 책임 원칙을 위배하기 때문에 시간이 갈수록 변경하기가 더 어려워지고 그로 인한 비용도 증가한다. 변경할 이유가 많이 쌓인 후에는 한 컴포넌트를 바꾸는 것이 다른 컴포넌트가 실패하는 원인으로 작용할 수 있다.

 

의존성 역전 원칙

도메인 코드는 애플리케이션에서 가장 중요한 코드이다. 영속성 코드가 바뀐다고 해서 도메인 코드까지 바꾸고 싶지는 않다.

 

💡 코드상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다.

 

 

사실 의존성의 양쪽 코드를 모두 제어할 수 있을 때만 의존성을 역전시킬 수 있다.

도메인 코드와 영속성 코드 간의 의존성을 역전시켜서 영속성 코드가 도메인 코드에 의존하고, 도메인 코드를 ‘변경할 이유’의 개수를 줄여보자.

도메인 계층에 레포지토리의 인터페이스를 둬서 리포지토리의 구현체가 영속성 계층에서 의존성 역전되도록 구성하여 도메인을 해방시킬 수 있다.

 

클린 아키텍처

 

 

이 아키텍처에서 계층들은 동심원으로 둘러싸여 있다.

 

💡 이 아키텍처에서 가장 중요한 규칙은 의존성 규칙으로, 계층 간의 모든 의존성이 안쪽으로 향해야 한다는 것이다.

 

이 아키텍처의 코어에는 주변 유스케이스에서 접근하는 도메인 엔티티들이 있다.

유스케이스는 앞에서 서비스라고 불렀던 것들인데, 단일 책임을 갖기 위해 조금 더 세분화되어 있다. 이를 통해 넓은 서비스 문제를 피할 수 있다.

클린 아키텍처에는 대가가 따른다. 도메인 계층이 영속성이나 UI같은 외부 계층과 철저하게 분리돼야 하므로 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야한다.

 

도메인 계층은 영속성 계층을 모르기 때문에 도메인 계층에서 사용한 엔티티 클래스를 영속성 계층에서 함께 사용할 수 없고 두 계층에서 각각 엔티티를 만들어야한다.

하지만, 이것이 바람직한 일이다. 이것이 바로 도메인 코드를 프레임워크에 특화된 문제로부터 해방시키고자 했던, 결합이 제거된 상태이다.

가령, JPA에서는 인자가 없는 기본 생성자를 추가하도록 강제한다. 이것이 바로 도메인 모델에는 포함해서는 안될 프레임워크에 특화된 결합의 예다.

 

육각형 아키텍처(헥사고날 아키텍처)

 

육각형 안에는 도메인 엔터티와 이와 상호작용 하는 유스케이스가 있다. 육각형에서 외부로 향하는 의존성이 없기 때문에 마틴이 클린 아키텍처에서 제시한 의존성 규칙이 그대로 적용된다.

대신 모든 의존성은 코어를 향한다.

애플리케이션 코어와 어댑터들 간의 통신이 가능하려면 애플리케이션 코어가 각각의 포트를 제공해야한다. 주도하는 어댑터에게는 그러한 포트가 코어에 있는 유스케이스 클래스 중 하나에 의해 구현되고 어댑터에 의해 호출되는 인터페이스가 될 것이다.

 

유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?

의존성을 역전시켜 도메인 코드가 다른 바깥쪽 코드에 의존하지 않게 함으로써 영속성과 UI에 특화된 모든 문제로부터 도메인 로직의 결합을 제거하고 코드를 변경할 이유의 수를 줄일 수 있다. 변경할 이유가 적을 수록 유지보수성은 더 좋아진다.

또한 도메인 코드는 비즈니스 문제에 딱 맞도록 자유롭게 모델링될 수 있고, 영속성 코드와 UI 코드도 영속성 문제와 UI문제에 맞게 자유롭게 모델링될 수 있다.