인프런 영문 브랜드 로고
인프런 영문 브랜드 로고

인프런 커뮤니티 질문&답변

Management Uiti님의 프로필 이미지

작성한 질문수

Microservice 구현 (with EDA,Hexagonal, DDD)

내부영역:응용서비스 구현(어플리케이션 헥사곤)-인터페이스 정의(유스케이스)

헥사곤 아키텍쳐 관련하여 문의드립니다.

작성

·

44

0

image.png

안녕하세요, 강의 내용 중에 궁금한 점이 있어 질문드립니다.

궁금한점이 제가 아는 헥사곤 아키텍쳐는 위와 같이, 입력포트는 인터페이스, 유스케이스는 입력포트의 구현체이고, 포트는 애플리케이션 코어와 외부 세계 사이의 경계점이라고 알고 있는데, 본 강의에서는 반대로 되어 있는데요, 혹시 경계를 유스케이스로 정하신 특별한 이유가 있으신지 궁금합니다.

답변 2

1

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

안녕하세요. 강의자 한정헌입니다.

헥사고널 아키텍처는 포트 엔 어댑터 패턴을 제안한 alistair cockburn를 기반으로 다양한 형태의 모습으로 소개되고 있습니다.

언급하신 모델은 인터넷에 일반적으로 많이 퍼져 있으나 소프트웨어 아키텍처가 다양한 변종이 있고 상황에 따라 여러 모델이 있을 수 있다 생각합니다.

제가 강의 시 참고한 모델은 다비 비에이라의 '헥사고날 아키텍처 설계와 구현'이라는 서적의 모델입니다.

헥사고널 아키텍처 모델을 3개의 헥사고널(도메인,애플리케이션,프레임워크)로 나누고 각각의 의미를 부여했는데 애플리케이션 헥사곤의 요소를 유스케이스-인풋포트-아웃풋포트로 구현하고 유스케이스를 인터페이스로 정의하고 인풋포트를 구현체로 활용했습니다.

다비 비에이라의 방식은 유스케이스를 단순한 구현체의 역할 보다는

이바 야콘슨의 '유스케이스 시나리오, '유스케이스 명세' 의 개념으로 파악한 것으로 애플리케이션 헥사곤이 갖는 의미 즉 '시스템이 정의 한 목표를 달성하기 위해 함께 동작하는 일련의 행위의 집합'를 구현한다. 를 강조하기 위해 유스케이스로 이러한 애플리케이션이 제공할 기능(일련의 행위 집합으로 시나리오 형태임)를 먼저 인터페이스로 정의한 것이라 생각합니다.

즉 간단히 말하면, 애플리케이션 헥사곤에서 가장 중요한 것은 도메인 헥사곤이 가진 비지니스 여러 개념을 복합적으로 활용하여 비지니스 목적에 맞는 시나리오를 구현하는 것인데, 그걸 명확히 표현한 방식이 이바 야콥슨 '유스케이스 명세'라는 방식이고, 이것을 강조한 구조라고 생각하면 됩니다.

저는 이 방식이 헥사고널 아키텍처 모델에 '유스케이스' 라는 개념을 설명하는데 타당 하다고 생각하여 이 방식으로 강의를 구성하였습니다.

물론 Management Uiti님이 제시하신 구조로 헥사고널 아키텍처 구조를 잡아도 타당하다고 생각합니다. Management Uiti님이 제시하신 구조는 비지니스와 기술을 어떻게 분리하여 어떻게 유연하게 할 것 인가? 에 초점을 맞췄다면 , 비에이라의 헥사고널 아키텍처는 한 발 더 나아가 그렇다면 비지니스 개념 과 활동을 어떻게 구조화 할 것인가를 좀 더 생각한 결과라 판단됩니다.

답변이 되었기를 바라며 감사합니다.

Management Uiti님의 프로필 이미지

상세한 답변 너무 감사드립니다!

"비지니스와 기술을 어떻게 분리하여 어떻게 유연하게 할 것 인가"와 "비지니스 개념과 활동을 어떻게 구조화 할 것인가"

이 부분이 매우 공감이 되었습니다.
강의 항상 잘 보고 있습니다. 감사합니다!

0

인프런 AI 인턴님의 프로필 이미지

안녕하세요, 인프런 AI 인턴입니다. Management Uiti님.

헥사고날 아키텍처에 대한 궁금증은 많은 개발자들이 공통적으로 갖는 질문 중 하나입니다. 헥사고날 아키텍처(포트와 어댑터 아키텍처)는 응용 프로그램을 심플하게 유지하면서도 확장성과 유지 보수성을 높이기 위해 탄생한 개념입니다. 이를 위해 “애플리케이션 코어”와 “외부 세계”를 명확히 분리하는 역할을 하며, 이때 “포트”가 중요한 역할을 담당합니다. 기본적으로 입력 포트와 출력 포트는 인터페이스로서 행동하며, 유스케이스는 이러한 포트의 구현체로 작동합니다.

그러나 강의에서 언급된 것처럼, 경계를 유스케이스로 설정할 수 있다는 설명은 포트가 아닌 애플리케이션 코어 상에서 유스케이스가 어떻게 설계 및 동작하는지 더 잘 이해하려는 의도를 가지고 있을 수 있습니다. 이는 강사님이 설명한 것처럼, 각 아키텍처의 원칙을 상황에 맞게 적용하는 다양한 방법 중 하나일 수 있으며, 주어진 도메인 내에서 가장 효과적으로 작동할 수 있는 방식으로 아키텍처를 설계하려는 시도일 수 있습니다.

혹시 DTO 클래스의 위치와 관련하여 유사한 고민을 했던 사례가 있는데, 참고하실 만한 강의 질문이 있습니다:

이 질문에서 강사님은 헥사고날 아키텍처에서 DTO의 위치에 대한 고민과, 유스케이스의 입출력 및 프레임워크와의 관계에 대해 설명하신 바 있습니다. 아키텍처 설계에서 트레이드오프와 타협이 필요할 때가 있으며, 이는 개발자의 의도와 도메인의 복잡성에 따라 달라질 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.