의존성 역전하기

(해당 내용은 '만들면서 배우는 클린 아키덱처'의 책을 공부하여 정리한 내용입니다)

단일 책임 원칙

단일 책임의 원칙의 일반적인 해석은 다음과 같다

하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다

이는 좋은 조언이지만 단일 책임 원칙의 실제 의도는 아니다

 

단일 책임 원칙의 실제 정의는 다음과 같다

컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다

만약 컴포넌트를 변경할 이유가 오로지 한 가지라면 컴포넌트는 딱 한 가지 일만 하게 된다 하지만 이보다 더 중요한 것은 변경할 이유가 오직 한 가지라는 그 자체다

하지만 안타깝게도 변경할 이유라는 것은 컴포넌트 간의 의존성을 통해 너무도 쉽게 전파된다

 

부수효과에 관한 이야기

잘못 구조화된 소프트웨어를 변경하는데 많은 비용을 지불하도록 만드는 경우는 부수효과의 영향이 크다 코드의 한 영역을 변경하면 다른 영역에서 부수효과 즉 예상치 못한 일들이 발생할 수 있다

그래서 우리는 더 좋은 소프트웨어를 만들도록 노력해야한다

 

의존성 역전 원칙

계층형 아키텍처에서 계층 간 의존성은 항상 다음 계층인 아래 발향을 가리킨다

단일 책임 원칙을 고수준에서 적용할 때 상위 계층들이 하위 계층들에 비해 변경할 이유가 더 많다는 것을 알 수 있다

그러므로 영속성 계층을 변경할 때마다 잠재적으로 도메인 계층도 변경을 해야 한다 그러나 도메인 코드는 애플리케이션에서 가장 중요한 코드이다

그래서 의존성 역적 원칙으로 해결해보자

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

 

엔티티는 도메인 객체를 표현하고 도메인 코드는 이 엔티티들의 상태를 변경하는 일을 중심으로 하기 때문에 먼저 엔티티를 도메인 계층으로 올린다

 

그러나 이제는 영속성 계층의 리포지토리가 도메인 계층에 있는 엔티티에 의존하기 때문에 두 계층 사이에 순환 의존성이 생긴다 이 부분을 바로 DIP(Dependency Inversioin Principle)를 적용하는 부분이다

도메인 계층에 리포지토리에 대한 인터페이스를 만들고, 실제 리포지토리는 영속성 계층에서 구현하게 하는 것이다

 

클린 아키텍처

로버트 C. 마틴의 클린 아키텍처에서는 설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI  기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다고 이야기한다

 

이는 도메인 코드가 바깥으로 향하는 어떤 의존성도 없어야 함을 의미한다

대신 의존성 역전 원칙의 도움으로 모든 의존성이 도메인 코드를 향하고 있다

 

 위 그림은 클릭 아키텍처가 어떻게 생겼는지 추상적으로 보여준다

 

이 아키텍처의 코어(도메인 계층과 애플리케이션 계층을 합쳐서 부름) 주변 유스케이스들에서 접근하는 도메인 엔티티들이 있다 앞에서 서비스라고 불렀던 것들인데, 단일 책임을 갖기 위해 조금 더 세분화돼 있다

이를 통해 전에 이야기했던 넓은 서비스 문제를 피할 수 있다

 

도메인 코드에서는 어떤 영속성 프레임워크나 UI 프레임워크가 사용되는지 알 수 없기 때문에 비즈니스 규칙에 집중 할 수 있다

 

클린 아키텍처에서는 대가가 따른다

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

 

가령 영속성 계층에서 ORM프레임워크를 사용한다고 할 때, 데이터 베이스의 정보를 가지고 있는 엔티티가 있다고 하면 도메인 계층에서 사용할 엔티티를 다시 만들어 데이터를 매핑시켜야 한다

이는 다른 계층 사이에서도 마찬가지다

 

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

클린 아키텍처에서 좀 더 일반적인 용어로 설명한 것이 육각형 아키텍처이다

육각형 안에는 도메인 엔티티와 이와 상호작용하는 유스케이스가 있다

육각형에서 외부로 향하는 의존성이 없기 때문에 마팅이 클린 아키텍처에서 제시한 의존성 규칙이 그대로 적용된다

 

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

클린 아키텍처, 육각형 아키텍처, 혹은 포트와 어댑터 아키텍처 중 무엇으로 불리든 의존성을 역전시켜 도메인 코드가 다른 바깥쪽 코드에 의존하지 않게 함으로써 영속성과  UI에 특화된 모든 문제로부터 도메인 로직의 결합을 제거하고 코드 변경할 이유의 수를 줄일 수 있다

그리고 변경할 이유가 적을수록 유지보수성은 더 좋아진다

 

 

---

생각 정리

• 용어 정리
  • 영속성 계층의 엔티티 -> JPA 엔티티 (데이터 베이스의 데이터를 가지고 있는 파일)
  • 도메인 계층의 엔티티 -> VO와 같이 JPA 엔티티를 매칭 시켜 데이터를 가지고 있는 파일
  • Use Cases -> 비즈니스 로직이 있는 서비스

이렇게 개발한다면 JPA의 영속성을 이용한 개발은 힘들지 않을까?

JPA의 영속성을 이용하지 않는다면 개발해야 할 코드가 많긴 하지만 엔티티가 수정되었을 때 부수효과가 적어지진 않을까?

매소드에게 좀 더 명확하고 한 가지 일만 할 수 있도록 로직을 개발해야겠다