의존성 역전하기

단위 책임 원칙

단위 책임 원칙은 "하나의 컴포넌트는 오로지 한 가지 일만 해야하고, 그것을 올바르게 수행해야 한다."고 알고 있지만 실제 의도는 "컴포넌트를 변경하는 이유는 오직 하나뿐이어야한다."이다. 변경할 이유가 한가지라면 수행해야 하는 일도 한가지이다. 만약 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없다.

E의 경우에는 의존하고 있는 컴포넌트가 없기 때문에 자기 자신이 변경할 이유가 있을 경우에만 수정하면 된다. 반면 A는 너무 많은 컴포넌트를 의존하고 있기 때문에 다른 어떤 컴포넌트가 바뀌든지 같이 바뀌어야 한다. 

 

의존성 역전 원칙

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

도메인 계층으로 엔티티를 올리고, 레파지토리 인터페이스를 도메인 계층에 올리고 실제 구현체는 영속성 계층에서 구현하게 한다.

 

클린 아키텍쳐

클린 아키텍쳐에서는 설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다. 이는 도메인 코드가 바깥으로 향하는 어떤 의존성도 없어야 함을 의미한다. 대신 의존성 역전 원칙의 도움으로 모든 의존성이 도메인 코드를 향하고 있다.

이 아키텍처에서 계층들은 동심원으로 둘러싸여 있다. 이 아키텍쳐에서 가장 주요한 규칙은 의존성 규칙으로 계층 간의 모든 의존성이 안쪽으로 향해야 한다는 것이다. 코어에는 주변 유스케이스에서 접근하는 도메인 엔티티들이 있다. 유스케이스는 앞에서 말한 서비스인데 단일 책임을 갖기 위해 조금 더 세분화 되어 있다.

 

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

 

하지만, 외부 계층과 철저히 분리돼야 하므로 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야 한다. ORM을 예로 들면 도메인 계층과 영속성 계층에서 각각 엔티티 클래스를 관리해야 한다. 두 계층 간 데이터를 주고 받을 때 두 엔티티를 서로 변환해야 한다. 이는 다른 계층 사이에서도 마찬가지이다.

 

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

육각형 안에는 도메인 엔티티와 사용하고 하는 Use Case가 있고 외부로 향하는 의존성이 없다.

육각형 외부에는 애플리케이션과 상호작용하는 다양한 어댑터들이 있다. 웹 브라우저와 상호작용하는 웹 어댑터도 있고, 일부 어댑터는 외부 시스템과 상호작용하며, 데이터베이스와 상호작용하는 어댑터도 있다.

왼쪽에 있는 어댑터들은 어플리케이션 코어를 호출하기 때문에 어플리케이션을 주도하는 어댑터들이고, 오른쪽은 어플리케이션 코어에 의해 호출되기 때문에 어플리케이션에 의해 주도되는 어댑터이다.