핵사고날 아키텍처 기반으로 멀티 모듈 설계 시 질문드립니다..

작성한 질문수 2

0

Part1 강의에서 설명드렸던 것처럼 헥사고날 아키텍처에서 Repository는 인터페이스만을 가리킵니다. 실제 그 인터페이스를 구현한 코드는 기술과 환경에 종속되기 때문에 어댑터에 인터페이스를 구현하는 클래스를 두고 만들어야 하죠. 다만, 스프링 데이터 JPA를 사용하는 경우 이 구현 클래스를 개발자들이 직접 만들지 않아도 스프링이 런타임에 자동으로 코드를 작성하고 컴파일해서 구현 기능을 사용하게 해줄 뿐입니다.

다시 정리하자면, Repository는 헥사고날 애플리케이션이 필요한 기능을 정의한 required interface이고요. 실제 구현은 그 외부 어댑터 영역에서 일어납니다. 스프링 데이터를 쓴다고 하더라도 QueryDSL이나 다른 데이터 기술을 사용한다면 어댑터 쪽에 실제 기능을 담당하는 리포지토리의 구현 코드가 만들어지면 됩니다.

0

안녕하세요, 인프런 AI 인턴입니다. chanboklee님께서 질문하신 내용은 헥사고날 아키텍처에서 Repository의 위치와 멀티 모듈 구성 방식에 대한 질문으로 이해했습니다.

헥사고날 아키텍처에서는 일반적으로 다음과 같이 구성할 수 있습니다.

• Application 레이어: Repository 인터페이스(Port) 정의
  
• Adapter 또는 Infrastructure 레이어: JPA, MyBatis 등을 사용하는 Repository 구현체(Adapter) 작성
  
• Domain 레이어: 핵심 비즈니스 규칙과 도메인 모델에 집중
  

따라서 Repository 인터페이스를 application 레이어에 두고, 실제 영속성 기술을 사용하는 구현체를 persistence 또는 infrastructure 모듈에 두는 구조는 의존성 역전 원칙에 부합합니다. 중요한 기준은 Repository라는 이름이나 패키지 위치 자체보다, 도메인 및 애플리케이션 코드가 JPA와 같은 구체적인 기술에 직접 의존하지 않는가입니다.

다만 멀티 모듈 구성에 정답이 하나만 있는 것은 아닙니다. 애플리케이션 단위로 모듈을 나눌 수도 있고, 도메인이나 애그리거트 단위로 나눌 수도 있습니다. 프로젝트의 규모, 팀 구조, 배포 단위, 모듈 간 결합도 등을 고려하여 선택해야 하며, 어떤 구조를 선택하든 각 모듈의 책임과 의존 방향을 명확히 하는 것이 중요합니다.

관련하여 다음 기존 답변들이 질문과 밀접합니다.

멀티 모듈 구성

멀티 모듈과 DDD·헥사고날 아키텍처를 함께 적용할 때의 접근 방법을 다룬 답변입니다. 지식공유자님께서는 Gradle 멀티 모듈 구성이나 도메인 중심의 모듈 분리 등 여러 접근 방법이 있으며, 모든 상황에 적합한 이상적인 멀티 모듈 구조는 없다고 설명하셨습니다. 선택한 구조의 이점과 단점, 트레이드오드를 고려해야 한다는 내용도 확인하실 수 있습니다.

의존성 방향과 관련된 질문이 있습니다.

Application 레이어에 Repository 인터페이스를 두고 Persistence 레이어에 구현체를 두는 구조에서, 의존성 방향과 헥사고날 아키텍처의 관계를 설명한 답변입니다. DIP를 적용하면 코드상의 의존 방향이 application을 향할 수 있으며, 이것은 헥사고날 아키텍처 또는 DIP가 적용된 레이어드 아키텍처로 이해할 수 있다는 내용입니다.

어플리케이션 , 도메인 계층질문

Application 레이어와 Domain 레이어의 역할 경계, Repository 인터페이스를 Application 레이어에 두는 이유, 여러 애그리거트의 로직을 조합하는 방법에 대해 설명한 답변입니다. 애플리케이션 서비스는 도메인 로직을 직접 구현하기보다는 필요한 애그리거트를 조회하고 도메인 기능을 호출하는 오케스트레이션 역할을 담당할 수 있습니다.

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