2장 - 의존성 역전하기

단일 책임원칙

컴포넌트를 변경할 이유가 오로지 한 가지라면 컴포넌트는 딱 한 가지 일만 하게 됩니다.

이는 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없음을 의미합니다.

 

하지만 변경할 이유는 컴포넌트 간의 의존성을 통해 너무 쉽게 전파됩니다.

예를 들어 컴포넌트 E를 변경할 유일한 이유는 새로운 요구사항에 의해 E의 기능을 바꿔야 할 때 뿐입니다.

 

하지만 컴포넌트 A의 경우 모든 컴포넌트에 의존하고 있기 때문에 다른 어떤 컴포넌트가 바뀌든지 같이 바뀌어야 합니다.

예를 들어 AController에서 BService, CService를 참조하고 있습니다.

이때 BService의 이름이 BBService로 바뀐다면? E 컴포넌트는 바뀔 필요가 없지만 AController에서는 BBService를 참조하도록 바뀌어야 합니다.

 

부수효과에 관한 이야기

다른 소프트웨어 회사에서 개발한 10년 된 코드를 받아서 진행한 프로젝트에 참여하게 된 경우가 있습니다.

코드가 실제로 어떤 일을 하는지 이해하기 어려웠고, 코드의 한 영역을 변경했더니 다른 영역에서 부수효과가 생겨나기 일쑤였습니다.

하지만 철저하게 테스트하고 이를 기반으로 리팩터링을 수행하였습니다.

 

하지만 이후에 클라이언트가 사용자 입장에서 굉장히 이상한 방식으로 동작하는 새로운 기능을 구현해 달라고 요청했습니다.

책의 저자는 조금 더 사용자 친화적이면서 비용이 저렴한 방식을 제안했습니다.

하지만 이는 아주 핵심적인 특정 컴포넌트를 변경해야 하는 작업이었습니다.

 

클라이언트는 이 제안을 거절했습니다.

이유는 과거에 이전 개발팀이 해당 컴포넌트를 변경했을 때 언제나 다른 무언가가 망가졌기 때문입니다.

 

의존성 역전 원칙

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

(의존성은 항상 다음 계층인 아래 방향을 가리키기 때문)

 

이를 토대로 영속성 계층을 변경할 때마다 잠재적으로 도메인 계층도 변경해야 합니다.

하지만 도메인 코드는 애플리케이션에서 가장 중요한 코드로 도메인 코드는 변경하고 싶지 않습니다.

 

DIP를 활용하면 됩니다.

 

리포지토리가 도메인 계층에 있는 인터페이스를 두고 이에 의존합니다.

실제 리포지토리는 영속성 계층에서 구현하게 하면 됩니다.

 

결과는 다음 그림과 같습니다.

 

클린 아키텍처

로버트 C. 마틴이 쓴 책으로 설계가 비즈니스 규칙의 테스트를 용이하게 하며, 비즈니스 규칙은 프레임워크, 데이터베이스 UI 기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다고 이야기합니다.

 

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

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

클린 아키텍처에서 중요한 규칙은 의존성 규칙입니다.

계층 간의 모든 의존성이 안쪽으로 향해야 합니다.

 

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

 

하지만 클린 아키텍처에는 대가가 따릅니다.

일반적으로 ORM 프레임워크는 데이터베이스 구조 및 객체 필드와 데이터베이스 칼럼의 매핑을 서술한 메타데이터를 담고 있는 엔티티 클래스를 필요로 합니다.

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

 

하지만 이로 인해 도메인 코드를 프레임워크에 특화된 코드에서 해방시킬 수 있습니다.

 

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

클린 아키텍처의 원칙들을 조금 더 구체적으로 만들어주는 육각형 아키텍처입니다.

 

 

애플리케이션 코어가 육각형으로 표현되어 이 아키텍처의 이름이 되었습니다.

사실 팔각형 아키텍처라도 불려도 상관없으며 애플리케이션이 다른 시스템이나 어댑터와 연결되는 4개 이상의 면을 가질 수 있음을 보여주기 위해 일반적인 사각형 대신 육각형을 사용했다고 합니다.

 

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

외부로 향하는 의존성이 없기 때문에 클린 아키텍처에서 제시한 의존성 규칙이 그대로 적용됩니다.

 

육각형 바깥에는 애플리케이션과 상호작용하는 다양한 어댑터들이 있습니다.

 

왼쪽은 애플리케이션 코어를 호출하기 때문에 주도적인 어댑터들이며, 오른쪽은 애플리케이션에 의해 주도되는 어댑터들입니다.

입력 포트는 호출되는 인터페이스가 될 것이며, 출력 포트는 코어에 의해 호출되는 인터페이스가 될 것입니다.

 

이런 핵심 개념으로 "포트와 어댑터" 아키텍처로도 알려져 있습니다.

 

핵심

어떤 아키텍처로 불리든 의존성을 역전시켜 도메인 코드가 다른 바깥쪽 코드에 의존하지 않게 함으로써 영속성과 UI에 특화된 결합을 제거하고 코드를 변경할 이유의 수를 줄일 수 있습니다.

 

변경할 이유가 적을수록 유지보수성은 더 좋아집니다.

 

삼색펜 스터디

• 빨강 : 핵심
• 파랑 : 나름 중요한 내용
• 초록: 재밌다는 생각이 드는 내용

 

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

잘못 구조화된 소프트웨어를 변경 하는 데 더 많은 비용이 지불된다.

interface를 활용하여 의존성을 역전시킬 수 있다.

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

 

도메인, 영속성 계층에서 각각의 엔티티를 만들어야 하고 서로 변환해야 한다.

육각형 아키텍처에는 입력포트와 출력포트가 있다.

 

철처하게 자동화된 테스트를 추가하여 리팩터링을 성공적으로 이루어냄 (과거에 토이 자바 프로젝트를 코틀린 프로젝트로 변환할때 많이 작성해둔 테스트가 크게 도움이 되었음)