헥사고날(Hexagonal) 아키텍처를 공부해보자 (with Layered, Clean Architecture)

✢ 데브톡 프로젝트에서 헥사고날 아키텍처를 적용해 보자고 제안해 보기 위해 공부하였고 내용을 정리하였다. 적용해보고자 하는 이유는 데브톡은 MSA로써 Port&Adapter 아키텍처인 헥사고날 아키텍처를 사용하는 게  의존성을 관리하기 좋을 것 같았기 때문이다.

(1) 전통적인 레이어드 아키텍처의 문제

일반적인 3계층 아키텍처

1. 데이터베이스 주도 설계를 유도한다.

전통적인 계층형 아키텍처의 토대는 데이터베이스이다.
웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스럽게 DB에 의존하게 된다.

우리가 보통 개발하는 애플리케이션의 목적은 비지니스를 관장하는 규칙이나 정책을 반영한 모델을 만들어서 사용자가 편리하게 사용할 수 있게 하는 것이다.
이때 우리는 State가 아니라 Behavior를 중심으로 모델링한다. 행동이 상태를 바꾸는 주체이기 때문에 행동이 비즈니스의 중심이다.
하지만 보통 데이터베이스 구조를 먼저 생각하고 이를 토대로 도메인 로직을 구현하는 경우가 있다.
이는 전통적인 계층형 아키텍처에서는 도메인이 영속성계층에 의존하고 있기 때문에 합리적일 수 있지만 비즈니스 관점에서는 맞지 않다.

ORM을 사용하는 경우 도메인 계층에서 데이터베이스 엔티티를 사용하는 것은 영속성 계층과의 강한 결합을 유발한다.

 

2. 계층의 경계를 강제할 수 없다.

전통적인 계층형 아키텍처에서는 전체적으로 전용되는 유일한 규칙은, 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능하다는 것이다.

따라서 만약에 상위 계층에 위치한 컴포넌트에 접근해야 한다면 간단히 컴포넌트를 아래 계층으로 내리면 된다.
하지만, 위 그림처럼 이러한 방식으로 해결하는 것은 문제가 숨어있다가 점점 쌓여 큰 문제가 될 수 있다.

  3.   계층을 건너뛰어 테스트하기 어려워진다.

개발하다보면 굳이 서비스를 거치지 않고 Repository에 바로 접근하여 간단하게 해결 가능한 상황이 자주 벌어진다.
이럴 경우 중간에 도메인 계층을 거치지 않고, 웹 계층에서 영속성 계층으로 바로 접근하는 경우가 발생한다.
이 또한 계층 개념을 무너뜨릴 수 있는 문제가 될 수 있다. 

웹 계층에 도메인 로직이 들어가게 되어 응집도가 많이 떨어질 수 있다.
또한, 웹 계층을 단위 테스트하는 경우 영속성 계층까지 Mocking 해야 하는 복잡도가 올라간다.

 

(2) 전통적인 레이어드 아키텍처의 대안

 1. 단일 책임 원칙 (SRP : Single Responsibility Principle)

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

변경해야 할 이유가 하나뿐이라면 해당 컴포넌트는 딱 한 가지 일만 하게 된다.
따라서, 어떠한 다른 이유로는 해당 컴포넌트에 대해서 신경 쓰지 않아도 된다는 의미이다.

 2.  의존성 역전 원칙 (DIP: Dependency Inversion Principle)

계층형 아키텍처에서는 계층 간 의존성이 항상 다음 계층인 아래 방향을 가리킨다.
단일 책임 원칙을 고수준에서 적용할 때, 상위 계층들이 하위 계층들에 비해 변경할 이유가 더 많다.
왜냐하면 전이 의존성을 포함하여 상위 계층으로 갈수록 의존성이 늘어나기 때문이다.

그러므로 도메인 계층은 영속성 계층에 의존하고 있기 때문에 영속성 계층이 변경될 때마다 잠재적으로 도메인 계층도 변경해야 한다.
하지만, 도메인 코드는 애플리케이션의 핵심인데 이것을 바꾸는 것은 쉽지 않은 일이다.

따라서, DIP: "코드상의 어떠한 의존성이든 그 방향을 바꿀 수 있다." 원칙을 적용하여 위와 같은 문제를 해결할 수 있다.
엔티티는 도메인 객체를 표현하고 도메인 코드는 이 엔티티들의 상태를 변경하는 일을 중심으로 하기 때문에 먼저 엔티티를 도메인 계층으로 올린다.

이제 영속성 계층의 레포지토리에 대한 인터페이스를 도메인 계층에 두어서 서비스는 같은 계층에 있는 레포지토리 인터페이스에 의존하므로 더 이상 도메인 계층은 영속성 계층에 의존하지 않고,
오히려 영속성 계층이 도메인 계층에 의존하고 있게 된다.(역전돼버림)

---

(3) 클린 아키텍처

1. 의존성 규칙

모든 소스코드 의존성은 외부에서 내부로, 고수준 정책을 향해야 한다. 따라서 비즈니스 규칙은 프레임워크, 데이터베이스, UI 기술, 외부 애플리케이션, 인터페이스로부터 독립적일 수 있다.

여기에도 DIP의 도움으로 모든 의존성이 도메인 코드를 향하고 있다.

해당 아키텍처의 Core에는 주변 UseCase에서 접근하는 도메인 엔티티들이 있다.
UseCase는 레이어드 아키텍처에서 서비스라고 불렀던 것들인데, SRP 원칙을 갖기 위해 유스케이스별로 세분화되어 그렇게 부른다.

Core 주변으로는 비지니스 규칙을 지원(ex: 영속성, UI)하는 애플리케이션의 다른 모든 컴포넌트들이 있다. 의존성이 안쪽으로만 흐름으로써 외부에 영향을 받지 않는 도메인 코드를 작성할 수 있는 것이다.

하지만, 클린 아키텍처에서는 한 가지 문제가 있다. 도메인 계층이 영속성이나 UI 같은 외부 계층과 철저히 분리돼야 하므로 엔티티에 대한 모델을 각 계층에서 유지보수해야 한다.

영속성 계층에서 ORM을 사용하는 경우, DB에 관련된 메타데이터를 가진 엔티티가 필요하다. 하지만, 도메인 계층에서는 ORM을 쓰던지 뭘 쓰던지 관심이 없기 때문에 영속성 계층과는 다른 순수한 도메인 엔티티가 필요하다.

이는 프레임워크와 도메인을 분리하여 준다.

내 생각을 잠깐 말하자면 ORM을 사용하기로 했고 추후에 변경여지가 없다고 판단되는 경우의 프로젝트에서는 "굳이 엔티티를 분리해서 관리할 필요가 있을까?"라고 생각한다. 따라서 이번 프로젝트에서는 클린 아키텍처와는 다르게 하나로 관리하고자 한다.

 

(4) 헥사고날 아키텍처

육각형 아키텍처 또는 Port&Adapter 아키텍처라고도 불리는데, 클린 아키텍처에서 조금 더 일반적인 용어로 설명한 아키텍처이다.

육각형 내에는 도메인 엔티티와 이와 상호작용하는 UseCase가 존재한다. 육각형에서 외부로 향하는 의존성이 없기 때문에 Clean Architecture에서 제시한 의존성 규칙이 그대로 적용되어 있다는 것을 알 수 있다.

육각형 바깥에는 애플리케이션과 상호작용하는 여러 가지 어댑터가 존재한다.
웹 브라우저와 상호작용하는 웹 어댑터, 데이터베이스와 상호작용하는 웹 어댑터, 인커밍 외부 애플리케이션 어댑터, 아웃고잉 외부 애플리케이션 어댑터가 존재한다.

애플리케이션의 코어와 외부의 어댑터 간의 통신이 가능하려면 포트가 필요한 것이다.

인커밍 어댑터에게는 포트가 코어에 있는 유스케이스 클래스 중 하나에 의해 구현되고 어댑터에 의해 호출되는 인터페이스가 된다.
아웃고잉 어댑터에게는 포트가 어댑터에 의해 구현되고 코어에 의해서 호출되는 인터페이스가 된다.

 

다음 편에서 계속됩니다.