Part 2 듣기전 복습하던 중, 아키텍처에 관한 질문이 있습니다.

Question

안녕하세요 토비님! 오랜만에 강의를 복습하다가 궁금한 점이 생겨 질문드립니다. 제가 헥사고날 아키텍처를 외부 서비스나 인프라 연동이 많은 시스템에서 주로 사용하는 구조 라고 이해하고 있었는데요. 강의에서는 비교적 작은 시스템에도 헥사고날 아키텍처를 적용하셔서, 제가 잘못 이해하고 있었던 건지 궁금합니다. 현재 작은 규모의 신규 프로젝트를 준비하고 있고, 도메인 모델 패턴과 풍부한 도메인 모델을 적용해보려고 합니다. 다만 외부 서비스 연동은 거의 없을 예정이라, 이런 경우에도 헥사고날 아키텍처를 적용하는 것이 적절한지, 아니면 오버엔지니어링이 될 수 있는지 판단이 잘 서지 않습니다. AI에게 물어봤을 때는 헥사고날 아키텍처 도입을 고려할 수 있는 기준으로 외부 연동의 수뿐만 아니라, 하나의 Port에 대해 구현체가 둘 이상 존재하거나 향후 교체 가능성이 있는지​ 도 이야기하더라고요. 강의에서 DDD와 헥사고날 아키텍처가 잘 맞는다고 설명해주셨는데, 결국 헥사고날 아키텍처를 선택할 때 외부 서비스 연동이 많은지 Port의 구현체가 여러 개이거나 교체 가능성이 있는지 도메인을 기술적인 의존성으로부터 분리할 필요가 큰지 같은 요소 중 무엇을 주요 기준으로 봐야 할까요? 작은 시스템이고 외부 연동도 거의 없다면 레이어드 아키텍처로 시작하는 것이 나은지, 아니면 풍부한 도메인 모델과 DDD를 적용한다는 이유만으로도 헥사고날 아키텍처를 선택할 충분한 이유가 있는지 궁금합니다.

tobyilee · Answer

제 생각엔 스프링 프레임워크를 사용해서 애플리케이션을 개발하면서 스프링 개발자들이 권장하는 방식으로 자연스럽게 코드를 설계하고 구성한다면, 대부분 헥사고날 아키텍처를 적용하고 있다고 봅니다. 아직 복잡하지 않은 시스템이라고 하더라도, 객체지향 설계원칙과 응집도/결합도라는 기본적인 원칙을 따르면 자연스럽게 헥사고날 아키텍처가 나오는 것이 정상입니다. 이건 스프링이 처음 등장했을 때부터 제안하고 지지했던 방식입니다. 도메인 모델 패턴도 마찬가지입니다. 빈약한 도메인(getter, setter 외에는 없는 엔티티만 사용하는) 모델 같은 것도 스프링의 개발 철학과 맞지 않습니다. 따라서 간단한 애플리케이션이니 스프링을 사용하지 않겠다는 결정을 하실 수는 있겠으나, 스프링으로 개발하기로 결정하셨다면 헥사고날 아키텍처를 자연스럽게 사용하실 수 있습니다. 한때 인기를 끌었던 클린아키텍처 책을 통해서 헥사고날 아키텍처가 알려지면서 그 책의 예제에 나온 방식으로 코드를 작성해야 헥사고날 아키텍처라는 잘못된 인식이 널리 퍼졌는데요. 그 방식은 너무 복잡한 관례를 요구합니다. 네이밍 규칙도 자연스럽지 않고 패키지가 아주 많아지죠. 그래서 Part1에서 헥사고날 아키텍처의 본래 의도와 적용 방법을 가능한 가장 단순한 방식으로 설명드리려고 했습니다. 그 부분을 잘 이해하고 따라가시면 되는데, 그래도 전통적인 자바 백엔드 개발 스타일과는 다른 부분이 있어서 고민이 되실 수는 있습니다. 포트 인터페이스를 의도 단위로 쪼개는 것들도 익숙하지 않으실 수 있습니다. 그냥 MemberService라는 인터페이스 하나에 Member 관련 기능을 다 넣어서 개발하는 것이 단순하기 때문에 아주 복잡해지지 않는다면 이런 방법을 선택하는 경우가 많았거든요. 이런 부분은 좀 고민이 필요한데, 사실 처음부터 완벽하게 포트를 나누고 시작하지 않으셔도 됩니다. 우선 Member 엔티티를 종심으로 Service, Port 인터페이스를 하나씩 만들고 시작하다가 나중에 메소드가 많아지면 그때 이걸 어떻게 나눠볼까 하고 인터페이스를 쪼개고, 구현 클래스도 복잡해지면 구현도 분리하는 방법도 가능합니다. 어쨌든 헥사고날 아키텍처가 지향하는 원칙은 포기하지 않으시면 좋겠습니다. 외부 시스템 연동이 없다면 required interface는 사실 스프링의 Repository 인터페이스 쓰는 것이면 충분합니다. 그것만 사용하셔도 이미 헥사고날 아키텍처를 하고 계신 거죠. 그런데 DDD는 많이 다릅니다. DDD는 상당히 복잡하고 거대한 철학과 원칙, 패턴의 집합이고 진정한 DDD는 아주 복잡한 도메인과 시스템에서 가치가 드러납니다. 그래서 제 강의는 DDD가 아니라고 굳이 강조를 하는 것이고요. 다만 거기서 소개된 좋은 패턴은 얼마든지 적극 사용할 수 있습니다. 엔티티, 값 객체, 서비스, 리포지토리, 애그리거트 같은 것들이죠. 질문에 답변을 드리자면, 스프링을 쓰신다면 헥사고날 아키텍처로 개발하시면 됩니다. 도메인과 관련된 로직을 담은 코드에 기술적인 코드가 혼재되지 않도록 해주시고요. 이미 리포지토리 인터페이스를 쓰면 그 부분은 90%쯤 성취된 것이죠. 반대로 UI(API 등등)쪽 기술이 도메인 로직을 담은 서비스 쪽으로 들어오지만 않게 해주시면 됩니다. ServletRequest, Cookie 같은 것들이죠. 그리고 도메인의 핵심 로직, 가장 중요한 불변식 등은 엔티티 안에 넣어주시면 됩니다. 그러면 도메인 모델 패턴까지도 적용하는 것입니다. 답변이 도움이 되었으면 좋겠습니다. 더 궁금하신 게 있으시면 질문해주세요.

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 차니님! 헥사고날 아키텍처는 외부 서비스 연동이 많을 때만 사용하는 아키텍처가 아닙니다. 핵심은 외부 시스템의 개수보다, 애플리케이션의 핵심 비즈니스 로직을 외부 기술이나 환경으로부터 분리하고 테스트하기 쉽게 만드는 데 있습니다. 따라서 외부 연동이 거의 없는 작은 시스템이라도 다음과 같은 경우라면 헥사고날 아키텍처를 적용해도 괜찮습니다. 도메인 로직이 단순 CRUD 이상으로 복잡한 경우 비즈니스 규칙과 상태 변화가 중요한 경우 도메인 모델을 중심으로 풍부하게 설계하려는 경우 향후 저장소나 외부 연동 방식이 변경될 가능성이 있는 경우 핵심 비즈니스 로직을 단위 테스트하기 쉽게 만들고 싶은 경우 반대로 단순한 CRUD 위주의 작은 시스템이고, 별도의 비즈니스 규칙이나 변경 가능성이 거의 없다면 헥사고날 아키텍처의 모든 요소를 처음부터 형식적으로 적용할 필요는 없습니다. 포트와 어댑터를 무조건 많이 만들기보다는, 도메인 로직과 외부 기술을 적절히 분리하는 핵심 원칙만 가져가는 방식 이 좋습니다. 토비님께서도 헥사고날 아키텍처는 도메인 모델 패턴이나 DDD를 반드시 함께 사용해야 하는 것은 아니며, 스프링으로 잘 개발하면 계층형 구조와 크게 다르지 않은 형태로 적용할 수 있다고 설명하셨습니다. 중요한 것은 “헥사고날 아키텍처를 사용한다”는 명칭보다, 서비스의 의도를 인터페이스로 명확히 표현하고 외부 시스템 의존성을 격리하여 필요한 로직을 테스트하기 좋은 구조로 만드는 것입니다. 참고하실 만한 기존 답변입니다. 백오피스 개발에도 헥사고날 아키텍처가 유용할까요? 단순 CRUD 시스템에서도 헥사고날 아키텍처를 적용할 수 있는지, 어느 부분에 테스트와 도메인 모델을 집중하면 좋은지 설명되어 있습니다. 헥사고날 아키텍처와 DDD 헥사고날 아키텍처를 처음부터 복잡하게 적용하기보다, 단순하고 명확하게 시작한 뒤 실제 문제가 드러날 때 단계적으로 발전시키는 접근을 권장하는 답변입니다. 질문에 첨부하신 이미지의 원본은 아래에서 확인하실 수 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.