헥사고날 아키텍처 시리즈 3. 헥사고날 아키텍처 시작하기

핵사고날 아키텍처

중심으로 향하는 의존성 방향

핵사고날 아키텍처는 의존성 역전 원칙을 적용해서 애플리케이션 계층으로 의존성이 생기도록 구성합니다. 계층형 아키텍처에서 웹 → 도메인 → 영속성으로 의존성이 존재했다면, 핵사고날 아키텍처에서는 웹 → 도메인 ← 영속성 방향의 의존성을 가집니다. 의존성 방향이 도메인 계층을 향하면 웹과 영속성 계층의 기술에 의존하지 않고 비즈니스 로직을 작성할 수 있습니다.

SpringBoot, JPA라는 한국형 국룰 조합을 사용한다고 하더라도 이러한 의존성 방향을 가져갈 이유가 있습니다. 하나의 애플리케이션이 더 작은 애플리케이션들로 나누어지는 경우에도 이러한 의존성의 방향이 도움을 줍니다. 도메인이 웹, 영속성 계층에 상관없이 독립적으로 작성되어 있기 때문에 비즈니스 요구사항에 따라서 작게 쪼개는 과정에 유리합니다.

지금 한창 개발하고 있는 소프트웨어에서 어떤 세부 도메인을 별도의 모듈과 프로세스로 쪼개는 작업을 해야한다고 생각해봤습니다. “아.. 안되겠는데” 인지 “어… 번거롭기는 해도 이렇게 하면 되긴 하겠네” 인지 생각해봤습니다. “되긴 하겠네”라는 생각이 들기 위해서 “안되겠는데”를 하나씩 풀어가는 과정이 바로 이러한 의존성을 방향을 도메인 계층으로 정리하는 과정이지 않을까 생각합니다.

의존성 방향을 바꾸고 나면 마주하는 현실들

도메인 계층에서는 영속성 계층을 모르게 하는 것이 목표이기 때문에, 영속성 계층의 ORM 엔티티와 도메인 계층의 도메인 클래스를 분리해야 합니다. 도메인 계층과 영속성 계층 사이에서 데이터를 주고 받을 때 변환하는 과정이 필수적으로 이루어져야 합니다. 이러한 과정이 번거롭기는 하지만 이것이 바로 결합이 제거된 상태입니다. 이러한 변환하는 과정은 Adapter라는 이름을 부여할 수 있습니다.

의존성 방향뿐만 아니라 더 챙겨야하는 것은

멀티모듈로 프로젝트를 잘 나누어서 시작했다고 하더라도, 의존성의 방향을 도메인 계층을 바라보도록 잘 설계했다고 하더라도, 하나의 모듈이 어쩔 수 없이 커지기 마련입니다. 모듈을 분리하는 시간, 분리 이후의 배포와 운영, 그리고 분리된 모듈을 담당할 사람 모두 부족하기 때문에 실제로 모듈을 분리하는 기쁨의 순간이 자주 찾아오기는 어렵습니다.

그러면 하나의 모듈 안에서 가지고 있는 패키지 구조가 중요해집니다. 이런 저런 기능들이 모두 추가되어도, 작년 초에 추가했던 기능의 클래스 이름이 생각나지 않아도, 새로운 팀원이 입사해도 필요한 코드를 빠르게 찾아갈 수 있어야 합니다. 그리고 이러한 표현력 있는 패키지 구조는 팀원들 모두에게 의도가 공유되어야 합니다.