헥사고날 퐁당 후기

헥사고날 퐁당 후기Back-end/DDD, Hexagonal ..2024. 1. 29. 12:58@philo0407

Table of Contents

샘플 코드는 이곳에 있습니다 (Kotlin + Spring + JPA)

인터넷의 많은 문서들을 읽었으나
클린 아키텍처 등 고전 명서를 정독하지 않고 적은 글입니다 :)
감안 부탁드립니다.. ^^

마침내 1년 가까이 한 번은 작성후 알아봐야지… 하고 생각만 했던 것을 작성해서 올렸다

(사실 구글링을 조금만 해보면 방대한 예시 코드들이 나온다… 어렵지 않게 공부할 수 있었다)

고대하던 헥사고날 예시코들 작성하면서 느낀 점을 기술한다…

요약

여러 형태의 설명을 해보자면

버전 1

DIP를 이용해서 비즈니스 로직을 클린하게/순수하게 두었음

버전 2

각 레이어간 인터페이스를 두어서 변경에 유연하게 만듬

구조

나처럼 레이어 아키텍처를 알고 있는 사람은 그걸 리펙터링한다고 생각해도 좋을 것 같다

기존의 레이어드 아키텍처

헥사고날 아키텍처

헥사고날 코드

이제 컨트롤러는 서비스를 바로 의존하지 않는다

컨트롤러와 서비스 사이에 인터페이스를 추가한다

이 인터페이스 이름의 post-fix는 "UseCase"이다 (담길 패키지의 이름은 "port/in" 이다)

(인터페이스는 ISP 원칙에 따라 분리하는 것으로 보인다)

컨트롤러는 이 인터페이스들을 사용하고

서비스는 각 인터페이스들을 구현한다

서비스와 리포지토리도 위에서와 같이 분리한다

인터페이스 이름의 post-fix는 Port이다. (패키지는 "port/out")

out port의 구현체는 JPA Repository일 수도 있고, 카프카 MQ일 수도 있다

느낀점

애플리케이션 코드가 구현체보다는 추상체(?)를 의존하기 때문에 코드가 확실히 클린해진 게 보인다

클린 아키텍처는 인터페이스를 통한 느슨한 결합/ 변경의 유연함 / 클린한 비즈니스 영역을 강조하는 것으로 보인다

도메인+비즈니스 영역을 web영역(in)과 DB영역(out)으로부터 보호하려고 노력하는게 보인다

그러나 작업량이 다소 많아 보인다

우선 패키지 부터가 숨이 다소 막힌다

또한 UseCase마다 클래스가 늘어나고, EntityMapper와 Entity로부터 분리한 도메인 또한 작업량에 한 획을 귿는다...

클래식한 Layer 3계층 아키텍처는 클린하지 못한가?

나는 클린하게 작성할 수 있다고 생각한다

기존 아키텍처 또한 레이어를 둠으로써 각 계층이 의존하는 기술들을 알맞게 분리한다

Cotroller는 Spring Web 혹은 Reactive 기술 의존을 하고 (사실 Reactive는 Repository 뼛속까지 타는 것 같다…)

Service는 Transaction(+AOP) 영역을

Repository 는 JPA | JDBC 등 DB접근 기술 영역을 담당한다

중복 비즈니스 로직 제거는 Validater나 DDD의 애그리거트가 처리해줄 수 있다 (Command)

또 CQRS를 같이 엮어서 복잡한 쿼리를 QueryDsl이나 Mybatis를 사용할 수도 있다 (Read)

그래서..?

개인적으로 in, out이 여러 개가 아닌 이상 선호하지는 않는 아키텍처인 것 같다

개발자마다 다르지만 나는 도메인 계층 (서비스+엔티티)이 제일 중요하다고 생각하는데,

도메인 로직뿐만 아니라 어떤 유형의 데이터가 DB에 저장되고, 이벤트가 발행되는지를 책 읽듯이 술술 읽어나가는 것도 좋아하기 때문이다

또 JPA를 사용할때 엔티티 관련 로직이 다소 복잡해지는 경향이 있는데

default method나, JpaRepository를 상속해서 몇 가지 편의 메서드를 추출한는 방법 등도 있다 (링크)

그래서 결론은…

헥사고날을 사용하지 않아도,

코드를 클린하게 유지하는 여러 방법이 있다보니 단순히 선택의 문제로 보인다

그외

(번역) 마틴 파울러에 따르면 육각형 아키텍처는 프레젠테이션 레이어와 데이터 소스 레이어 간의 유사성을 이용해 인터페이스로 둘러싸인 코어로 구성된 대칭형 구성 요소를 만들 수 있다는 장점이 있지만, 레이어로 표현하는 것이 더 나은 서비스 제공자와 서비스 소비자 간의 고유한 비대칭성을 숨길 수 있다는 단점이 있습니다.

대칭성이라…

사실은 논리적으로 대칭적이지 않은 것을 미학적으로 대칭적으로 보이게 하는 것은 심미적으로는 좋지만… 순서를 확인할 수 있는게 더 좋아 보인다