정의
위키피디아의 헥사고날 아키텍처의 정의는 아래와 같다.
The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters. This makes components exchangeable at any level and facilitates test automation.
해석하자면 헥사고날 아키텍처는 포트와 어뎁터를 활용해서 컴포넌트들의 의존성을 낮추고 테스트를 용이하게 만들 수 있다는 내용이다.
이번 글에서는 이 헥사고날 아키텍쳐가 왜 나오게 됐는 지, 포트와 어뎁터가 무엇인 지, 이를 어떻게 구현할 수 있을 지 정리해보려고 한다.
헥사고날 아키텍쳐 - Layerd Architecture 단점 보완
기본적으로 헥사고날 아키텍쳐는 레이어드 아키텍쳐의 단점을 보완하려고 만들어졌다.
위 그림은 레이어드 아키텍쳐의 전형적인 구조도로 "각 계층 별로 맡은 역할을 수행하고 다음 레이어드로 넘겨준다"
이때 중요한 것은 비즈니스 플로우가 PRESENTATION LAYER -> INFRASTRUCTURE LAYER로 흐르고 있고 의존성도 같은 방향으로 흐르고 있기 때문에 자칫 잘못하면 DB 의존적인 코드가 작성될 수 있다.
여기서 말하는 DB 의존적인 코드는 데이터베이스가 변경됐을 경우, 모든 비즈니스 로직에 영향을 끼칠 수 있는 코드다. 예를 들어 MySQL -> Elastic Search로 DB를 변경했을 경우, 인프라, 도메인, 어플리케이션, 심지어 프레젠테이션 레이어도 변경될 수 있다는 얘기다.
그렇다면 헥사고날 아키텍쳐는 이를 어떻게 해결할까??
핵심 키워드는 바로 DIP(의존성 역전)이다. DIP는 "구체화된 하위 객체보다 추상화된 상위 객체에 의존해라!"라는 내용인데 이는 추상화되면 추상화 될수록 객체 간의 의존성을 떨어뜨릴 수 있기 때문이다.
코드가 디테일해지면 해질수록 수정하기 어렵다. 따라서 최대한 코드를 덜 작성한 거에 의존성을 가지는 방향으로 구현해야한다. 그렇다면 최고로 코드를 덜 작성한 것을 무엇일까? 바로 인터페이스다. 인터페이스는 구현이 전혀 없다. 따라서 인터페이스를 바라보게 되면 코드 수정에 있어서 매우 매우 유연한 구조가 된다. 헥사고날에서 인터페이스가 바로 port이다.
Port? Adapter?
티스토리 블로그에서 그림으로 잘 정리된 내용이 있어서 가져왔다.
출처 : 백문이불여일타 - 헥사고날 아키텍처(Hexagonal Architecture) 코드로 이해 해보기
아래의 그림은 전형적인 Layerd 아키텍쳐 그림이다. 보면 계층을 내려갈수록 하위 계층에 의존적인 구조를 띈다.
이때 각 계층 사이에 interface를 추가한 후, 컨트롤러는 서비스 인터페이스를, 서비스는 레포지토리 인터페이스를 바라보도록 수정한다.
그리고 모든 비즈니스 로직을 위와 같이 수정하면 아래와 같아지는데 컨트롤러와 레포지토리는 Adapter로, 각 인터페이스는 Port로 명칭이 바뀐다.
여기서 중요한 것은 서비스 계층은 유즈케이스라는 이름으로 각각의 포트로 부터 보호된다. 즉 헥사고날 아키텍쳐는 서비스 계층, 비즈니스 로직을 외부 변화로부터 보호하는 아키텍쳐라고 볼 수 있다.
비즈니스 로직을 무엇으로부터 보호해야해?
위에서 헥사고날 아키텍쳐의 핵심은 외부 변화에 비즈니스 로직을 보호하는 것에 있다고 했다. 그렇다면 외부 변화는 무엇이 있길래 보호해야하는 것일까??
컨트롤러
우선 컨트롤러 부분에서의 차이는 바로 데이터 시리얼라이즈 변화다. 예로 부터 웹 서버에서 데이터를 내려주는 방법은 html을 바로 내려주는 것이다.(서버 사이드) 그러나 최근 앱의 등장, Client 컴퓨터 성능 향상, 브라우저 컴파일러의 발전 등으로 REST API가 등장하였고 JSON, XML 등으로 데이터를 뿌려주기 시작했다. 더 나아가서는 GraphQL, gRPC 등이 등장하면서 컨트롤러에서 다양한 데이터 형태로 보내야하고 이러한 과정에서 비즈니스 로직이 수정될 수 있다.
레포지토리
레포지토리, 즉 DB는 데이터 형태가 다양해지면서 그 종류 또한 다양해졌다. 예를 들어 기존의 강세였던 SQL과, 비정형 데이터를 더 잘 다룰 수 있는 NoSQL, 또 검색에 특화된 검색엔진, 관계형 데이터에 강한 그래프 데이터베이스 등 상황, 도메인에 맞게 다양한 데이터베이스를 쓸 수 있게 됐다. 그렇기 때문에 DB를 변경할 가능성이 높아지고 그에 따라 비즈니스 로직이 수정될 가능성이 있다.
정리
헥사고날 아키텍쳐는 비즈니스 로직을 캡슐화하는 아키텍쳐로 생각된다. 이는 다양한 외부 서비스, API를 사용하면서 생길 수 있는 문제를 해결할 수 있다. 이것만 봤을 땐 매우 매우 좋아보이는 아키텍쳐인데 과연 단점은 없을까?? 인터넷 리서치로는 찾을 수 없었지만 개인적으로는 몇 가지 단점이 있을 것 같다.
하나는 설계 난이도가 올라갈 것이다. 인터페이스 설계는 정말 어렵다. 잘못 설계하면 차후에 수정하기 어렵기 때문에 모든 가능성을 고려해서 인터페이스를 설계해야 한다. 그리고 Adapter 복잡도가 상승할 것이다. 전에 구현한 인터페이스에 맞게 Adapter를 구현해야하기 때문에 특정 db나 데이터 시리얼라이저 같은 경우에 복잡도가 크게 상승할 수 있다.
물론 위의 두 단점을 커버할 정도로 좋은 장점이 많은 아키텍쳐이기 때문에 많은 개발자들이 쓸 것이다. 따라서 나도 열심히 공부해서 잘 사용해볼 것이다!!!
P.S. 회사에서 쓰는 아키텍쳐 구조여서 정리해본 것이다.
