서론

반년 전 만들면서 배우는 클린 아키텍처 책을 읽으면서 헥사고날 아키텍처에 대해 접하게 되었다.
당시 도움을 주시던 멘토님은 굉장히 부작용이 크다고 도입했다가 후회하는 회사들이 많다고 하셨는데, 내 눈엔 굉장히 매력적으로 다가왔다.

똥은 찍어봐야 알기 때문에 사이드 프로젝트에 녹여볼 생각이다.

헥사고날?

헥사고날 아키텍처는 시스템 내부 도메인과 외부의 입출력 포트로 구분하고, 이들을 연결하는 어댑터*로 구성하는 것이다. 내부 도메인은 시스템의 핵심 비즈니스 로직이 위치하는 영역을 나타내며, 외부 포트와 어댑터는 내부 도메인과 외부 환경 간의 상호작용을 관리한다.

헥사고날 아키텍처 하면 가장 많이 사용되는 사진 두장을 가져왔다.
핵심은 외부 요인에 의한 Application 내부 도메인의 변경을 "최소화" 한다는 것이다.

장점

• 유연성과 확장성 : 내부 도메인과 외부 환경 간의 분리를 통해 시스템의 확장성과 유연성이 향상된다.
• 유지 보수성 : 변경이 용이하기 때문에 유지 보수성이 향상된다.
• 테스트 용이성 : 내부 도메인과 외부 인터페이스 간의 분리로 단위, 통합 테스트의 용이성이 향상된다.
• 도메인 중심 설계 : 내부 도메인에 집중할 수 있어 시스템의 복잡도를 낮추고, 각 도메인 별로 모듈을 생성하여 응집도가 올라간다.

단점

• 복잡성 : 더 많은 계층으로 나누고, 인터페이스와 어댑터를 도입하기 때문에 시스템 복잡도가 늘어난다. 이때 불필요한 추상화와 코드량이 매우 많아진다.
• 오버 엔지니어링 : 작은 규모의 프로젝트나 간단한 애플리케이션에서 도입하기엔 러닝커브와, 과도한 설계로 자원이 낭비된다.

원칙

컴포넌트의 분리

소프트웨어 아키텍처에서 중요한 개념으로, 시스템을 여러 개별적인 부분으로 나누는 것을 말한다. 각 컴포넌트는 특정한 기능이나 역할을 수행하며, 이들 컴포넌트는 독립적으로 개발, 테스트, 유지 보수할 수 있도록 설계되어야 한다. 이를 통해 시스템의 모듈성, 유연성, 유지 보수성이 향상된다.

컴포넌트 분리는 헥사고날 아키텍처에서 포트와 어댑터로 나누는데 중요한 개념이다. 적절하게 분리하고, 의존성을 설계하는 것이 핵심이다.

인터페이스와 의존성

헥사고날 아키텍처에서 인터페이스와 의존성에 대한 원칙이 있다. OOP의 원칙과 매우 흡사하다.

• 클라이언트는 필요한 기능만 포함하는 작은 인터페이스에 의존한다.
• 상위 모듈은 하위 수준의 구현에 의존하지 않고 추상화에 의존한다.

어댑터

내부 도메인을 더욱 단단히 만들기 위해 어댑터를 사용한다.

• 입력 포트 어댑터
  외부 시스템이나 사용자 인터페이스와의 상호 작용을 처리한다.
  외부 요청을 내부 도메인이 이해할 수 있는 형태로 변환하여 내부 도메인에 전달한다.

• 출력 포트 어댑터:
  내부 도메인에서 발생하는 이벤트나 데이터를 외부 시스템에 맞게 변환하여 전달한다.

• 플러그인 어댑터:
  외부 시스템이나 라이브러리를 내부 도메인에 통합하기 위해 사용한다.
  외부 시스템의 인터페이스를 내부 도메인이 이해하는 인터페이스로 변환한다.
  특정 외부 시스템을 변경하거나 대체할 때도 플러그인 어댑터를 변경하여 유연하게 대응할 수 있다.

마무리

아직까지 멘토님이 말씀하신 헥사고날의 치명적인 단점을 모르겠다. 헥사고날 아키텍처는 객체지향을 가장 잘 표현한 아키텍처라고 생각이 든다.

사이드 프로젝트에서 헥사고날 아키텍처를 사용하고 있는데 API 를 완성하지 않았음에도 코드량이 확실히 많긴 하다. 단점중 하나인 오버 엔지니어링이 될 것 같지만, 도전하고 있다.
반면에 유연성과 유지보수성, 그리고 여러 개발자가 함께 개발할 때 인터페이스의 장점 또한 따라올 것이다.