Hexagonal Architecture 적용하기

https://github.com/Seungkyu-Han/Toge-do-backend

GitHub - Seungkyu-Han/Toge-do-backend: Toge-do 앱의 백엔드 리포지토리입니다

 

https://engineering.linecorp.com/ko/blog/port-and-adapter-architecture

지속 가능한 소프트웨어 설계 패턴: 포트와 어댑터 아키텍처 적용하기

해당 글을 참고하였습니다.

 

현재의 시스템 구조이다.

여러개의 서버에서 사용하는 부분을 module로 추출해서 멀티모듈로 개발을 하다 보니, Hexagonal Architecture를 적용하고 싶어졌다.

이런 생각이 빨리 들었으면 더 쉽게 적용할 수 있었을텐데...아쉽니다.

 

우선 Heaxgonal Architecture의 설명이다.

애플리케이션의 핵심 비즈니스 로직과 외부 시스템(데이터베이스, API등)을 분리하여 시스템을 더욱 유연하고 테스트하기 쉽게 만드는 것을 목표로 하는 소프트웨어 설계 패턴이다.

외부에 포트와 어댑터만 노출하기 때문에 Ports and Adapters 패턴으로도 불린다고 한다.

이런 식으로 외부에 포트를 노출하고 있으며, primary 포트(어댑터)와 secondary포트(어댑터)로 나뉜다.

 

primary는 외부에서 요청을 받아야 동작하는 요소들을 말한다.

이런 식으로 Service로 인터페이스를 제공하고 있기에, 해당 인터페이스에 있는 메서드들이 포트가된다.

컨트롤러는 HTTP API의 요청을 받아 Service의 인터페이스를 연결해주고 있기 때문에 어댑터이다.

 

secondary는 애플리케이션이 호출하면 동작하는 요소들을 말한다.

보통 Repository 인터페이스로 개발을 하기에 Repository가 포트이고, 해당 Repository를 상속받는 구현체가 어댑터가 된다.

 

보통 애플리케이션이 핵심 로직으로, 변경이 굉장히 자주 일어나게 된다.

그렇기에 요청을 하고 받는 어댑터와의 결합도를 낮추어야 하는데, 이를 포트를 의존하는 방법으로 해결한다.

 

만약 여기에 빠른 속도를 위한 Redis를 추가하더라도, 기존의 핵심 도메인에는 영향을 주지 않고, 어댑터만 추가하게 되는 것이다.

이 때더 포트가 애플리케이션과 도메인을 보호하게 됩니다.

 

이외에도 더 많은 개념이 있는데, 일단 여기까지만 소개하고 현재 진행중인 프로젝트에 적용하는 방법을 생각해보았다.

 

우선 기존에도 도메인은 model module로 추출하여, 핵심 로직을 작성해 사용하고 있었다.

이 모듈을 그대로 domain으로 사용할 수 있을 것 같았다.

그 모듈을 중심으로 구성해보면

 

이렇게 만들 수 있지 않을까 생각이 든다.

 

사실 이렇게 블로그를 작성하고 다시 설계하면서 생각해보니, 기존의 설계와 크게 다르지 않다는 것을 알게되었다.

이렇게 만들면 각 단계에서 수행할 테스트도 명확해지기 때문에 좋았었다.

 

이 Hexagonal Architecture가 클린코드에서 굉장히 중요한 개념이라고 한다.

 

앞으로도 중복되는 코드들을 제거하고, 더 나은 설계를 적용하기 위해 다양한 방법을 생각해보도록 하자.