의존성 역전하기

단일 책임 원칙

하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다.
컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.

만약 컴포넌트를 변경할 이유가 한가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요 없다.
실제 컴포넌트를 구현할 때 하나의 컴포넌트가 단일 기능으로 만들기 참 어려운 것 같다.
처음에 만들 때는 단일 기능을 생각하고 만들지만 시간이 지나 비슷한 기능을 만들 일이 생긴다면 이전 컴포넌트의 병합 유혹을 많이 느낀다.
그래서 막상 프로젝트가 시간이 지나면 이전의 단일 기능 컴포넌트가 여러 이유로 변경 되고 컴포넌트의 신뢰도가 떨어지는 경우가 많이 발생한다.
그 외에도 테스트 코드를 유기적으로 바꿔줘야 한다.
반성하자...

부수효과

코드의 한 영역을 변경했더니 다른 영역에서 부수효과가 생겨나기 일쑤였다.

레이어드 아키텍처를 주로 사용해온 경험으로 너무 공감 되는 내용이었다.
처음 설계한 사람 조차도 레이어드 아키텍처를 사용하다 보면 계층간의 느슨한 관계의 유혹을 많이 받는다.
점차 계층간의 커플링이 높아지고 나중에는 내가 설계한 코드가 기술 부채로 남는 참사가 난 경우도 많았던 것 같다. (마음이 아프다....)
그래서 아키텍처를 클린하게 유지하는 것이 무엇보다 중요하고 유지보수와 확장에 친화적으로 만들자!!

의존성 역전 원칙

코드상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다.
도메인 코드와 영속성 코드 간의 의존성을 역전시켜서 영속성 코드가 도메인 코드에 의존하고, 도메인 코드를 변경할 이유의 개수를 줄여보자

위와 같이 계층간의 DIP를 하려면 해당 레이어의 계층별 인터페이스가 있는 것이 좋다
만약 인터페이스가 없다면 영속성 계층의 레포지토리가 도메인 계층에 있는 엔티티에 의존하기 때문에 두 계층 사이에 순환 의존성이 생긴다.

클린 아키텍처

설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI기술
그 밖에 외부 어플리케이션이나 인터페이스부터 독립적일 수 있다.

• 엔티티 : 아키텍처의 코어
• 유스케이스 : 도메인 계층에 있는 서비스 영역, 단일 책임을 갖기 위해 조금 세분화돼 있다.
• 인터페이스 어댑터 : 컨트롤러, 게이트웨이 등 도메인과 인프라스트럭처의 중개자 역할
• 프레임워크 & 디바이스 : 가장 바깥쪽 레이어로 데이터베이스나 웹 프레임워크 등 일반적으로 프레임워크나 도구로 구성

헥사고날 아키텍처

Ports and Adapters 아키텍처로도 알려져 있다.

클린 아키텍처처럼 육각형 아키텍처도 계층으로 구성할 수 있다.

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

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