post/home-hexagonal-architecture/

[giscus[bot]]

post/home-hexagonal-architecture/

카카오페이 홈 서버 개편 후 운영 과정에서 Hexagonal Architecture 아키텍처 적용, 제거 경험을 공유합니다.

https://tech.kakaopay.com/post/home-hexagonal-architecture/

[LichKing-lee]

요즘 여기저기서 헥사고날에 대한 얘기가 많은데 실전에서 사용해본 후기를 볼 수 있어서 참 좋네요

[MCprotein]

좋은 글 감사합니다.
관심사 단위 패키징에 대한 정보를 보려면 어떤 키워드로 검색해보는게 좋을까요?

[d0lim]

안녕하세요,

기능별 패키징으로 검색해보시면 레이어 단위로 패키징하는 것과 비교하는 아티클이 많이 있을 듯 합니다!

감사합니다.

[Lifeclue]

좋은 글 잘 읽었습니다. 헥사고날 아키텍처는 도메인을 건강하고 지속 가능하게 유지하는 것을 추구합니다. 만약 전환 과정에서 도메인을 명확히 했다면 경계가 좀 더 명확해지고 아키텍처 정착에 도움이 되지 않았을까 하는 아쉬움이 남네요.

[d0lim]

안녕하세요.

전환 과정에서 도메인을 명확하게 하기 위한 시도 자체는 많이 했는데 결국 완전히 해내지 못한 부분이 저도 아쉬운 부분입니다.
아마 도메인과 그 경계를 명확히 정의할 수 있었다면 분명히 유효한 방향으로 나아갈 수도 있었을 것 같습니다.

조심스럽게 말씀드려 보자면 그럼에도 불구하고 도메인(코어) 모듈을 사용하는 in adapter 모듈이 단일 모듈이라는 부분에서 개인적으로 도메인 모듈의 재사용성을 높이지 못한단 점을 들어 카카오페이 홈 서버엔 헥사고날 아키텍처는 부적합하다고 생각하긴 합니다.
헥사고날 아키텍처는 in / out 방향에 대해 둘 다 경계를 느슨하게 결합하는 것을 강조하는데, in 방향의 어댑터로 붙을 모듈이 HTTP 서버 밖에 없고, 이 단일 모듈을 위해 매핑 로직을 매번 작성해야 하는게 생산성을 저해한다고 판단했습니다.
gRPC나 웹소켓 서버를 서빙해야 하는 요구사항이 생기면 아마 다시금 고민해볼 것 같은데, 현재로썬 그렇지 않은 상황이라 걷어내게 된 부분도 있습니다.

다양한 상황을 다시금 생각해보게 되네요. 생산적인 피드백 감사합니다.

[simsimeie]

많은 생각을 하게 하는 글이네요 트렌드가 시시각각 변함에 따라 변동성이 크고, 초개인화를 요구하는 홈화면에서 abstration을 통해 공통된 역할을 추출할 수 있을까? 그 역할의 생명주기는 얼마나 될까? 구조적으로 의존성 역전은 만들 수 있지만 실제적으로는 끌려다닐 수밖에 없지 않을까(요건에 맞게 인터페이스를 열심히 수정해가며..)? 그렇다면 이것은 진정한 의미의 의존성 역전일까? 저 역시 헥사고날은 보일러플레이트 코드가 많아지는 단점만 있을 뿐 적용하면 더 없이 좋은 클린 아키텍처라 생각했지만 이 글을 읽으며 다시 생각하게 되네요 좋은 글 감사합니다.

[junglast]

멋있네요

[chunhodong]

좋은 글 잘 읽었습니다.
위에서 DTO 분리 유지를 위해서
"이를 위해 응답에 대한 DTO 클래스를 Namespace로 인식하고 Nested Class를 활용하여 혼동을 최소화했습니다."라고 하셨는데
이 부분 조금 더 자세하게 알 수 있을까요??

[d0lim]

안녕하세요, 가령 API 응답에도 image라는 필드가 있고, 연동 서비스 API 응답에도 image라는 필드가 존재할 수 있습니다.
이런 상황에서 다음과 같이 처리했다고 보시면 됩니다.

// API 응답에 대한 Image를 Nested Class로 선언
data class ApiResponse(
    val image: Image,
) {
    data class Image(
        val url: String,
    )
}

// 연동 클라이언트 응답에 대한 Image를 Nested Class로 선언
data class ClientResponse(
    val image: Image,
) {
    data class Image(
        val imageUrl: String,
    )
}

이렇게 선언하면 예를 들어 다음과 같이 혼동을 줄여 사용할 수 있을 것입니다.

fun foo(): ApiResponse {
    val clientResponse = client.get()
    return ApiResponse(
        image = ApiResponse.Image(url = clientResponse.image.imageUrl)
    )
}

대단한 것은 아니지만 DTO 클래스가 굉장히 많은 홈 서버 코드에서는 개인적으로는 좀 더 관리하기 편한 방식이라고 생각하고 있습니다.

[energyFull]

사실 헥사고날 아키텍쳐의 핵심은 어떤 변동이 있더라도 어댑터 부분에서 해결하고 핵심 비즈니스 로직만큼은 지켜내는 것이겠죠.

사실 홈화면을 렌더링하기 위한 서버일 뿐이라면 기존의 레이어드로 충분하지 않나 생각이 듭니다...

[roovies]

좋은 글 잘 읽었습니다.

[HYEONSIKOH]

핵사고날 아키텍처랑 DDD 공부 중인데, 많은 도움이 되었습니다 감사합니다

[jaehanbyun]

좋은 글 정말 잘 읽었습니다.
공유해주셔서 정말 감사합니다 !