[클린 아키텍처 02] Dependency Inversion (의존성 역전하기)

<< 클린 아키텍처 02 >>

의존성 역전하기

백엔드 개발자라면,, 누구나 한번쯤 달달달 외웠을 SOLID 원칙! 

그 중 단일 책임 원칙과 의존성 역전 원칙에 대해 자세히 살펴보도록 합시당

 

단일 책임 원칙

우리가 흔히 아는 단일 책임 원칙은 하나의 컴포넌트는 오로지 하나의 역할만을 해야한다는 것이다.

그러나 클린 아키텍처의 저자는 단일 책임 원칙을 요로케 표현했당:

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

 

컴포넌트가 변경되는 이유가 오직 하나 뿐이라면 우리가 다른 이유로 소프트웨어를 변경하더라도 이 친구는 절대 변하지 않는다는 것이다;

 

요렇게 세 개의 클래스가 있을 때,

만약 C가 어떤 함수명을 바꿨다. 그럼 그 친구를 참조하고 있던 A와 B도 어쩔 수 없이 바꿔야함 ㅠ_ㅠ 👎👎👎

C는 어느 곳에도 의존하지 않기 때문에 지멋대로 바꾸기 완전 가능👍👍👍

C가 변경되는 이유 : 비즈니스적 요구사항이 바뀌었을 때

A가 변경되는 이유 : 비즈니스적 요구사항이 바뀌었을 때, C가 오타내서 함수명 바꿀 때, B가 하나의 함수를 두개로 분리시켜버렸을 때 어쩌구 저쩌구 등등

 

의존성 역전 원칙

코드상의 어떤 의존성이든 그 방향을 바꿀 수 있다

 

도메인 코드와 영속성 코드 간의 의존성을 역전시켜 도메인 코드를 '변경할 이유'의 개수를 줄여보자!

 

 

1) 기존에 사용하고 있떤 엔티티를 도메인 계층으로 옮긴다.

2) 영속성 계층의 레포지토리가 도메인 계층에 있는 엔티티에 의존 -> 순환 의존성이 생김

3) 도메인 계층에 레포지토리 인터페이스를 만들고, 실제는 영속성 계층에서 구현한다. 

 

클린 아키텍처

로버트가 말하는 클린 아키텍처는? 

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

요러케 모두 도메인을 향해 집중하는 구조여야함 ㅋㅋ

도메인 코드에서는 어떤 영속성 프레임워크나 UI 프레임워크가 사용되는지 알 수 없다!

오로지 비즈니스 규칙에만 집중할 수 있다는 장점을 가지고 있슴 ㄷㄷ 

 

그러나 크나큰 문제점(매우 귀찮은)이 있는데, 바로 엔티티 클래스를 각 계층마다 만들어야 한다는 것이다.

예를 들어 JPA 엔티티를 사용한다고 할 때, 계층형에서는 그냥 도메인 계층에서 엔티티 불러서 사용하잖아염?

그런데 클린 아키텍처 같은 경우는 도메인 계층이 영속성 계층을 의존하지 않고 있다! 각각 다른 엔티티 클래스를 구축해줘야 한다

이것이 곧 결합이 제거된 상태..! (지만 매우 귀찮다)

 

육각형 아키텍처

 

육각형 아키텍처는 알리스테어 콕번이 만든 용어로 클린 아키텍처와 동일한 원칙을 지니고 있다!

요 육각형에서 외부로 향하는 의존성이 없고, 모두 코어로 향한다! == 클린 아키텍처 원칙과 동일

요걸 기반으로 코드를 작성해 볼 예정!