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

멀티 모듈 구조에 대해서는 이후 강의에서 다루겠지만, 항상 이렇게 해야한다라는 절대적인 기준은 없습니다.

여기서 모듈은 아마도 Gradle 모듈이겠죠? 이걸 계층 레벨에서 분리한다면 지금 말씀하신 api / core(application, domain)이 가장 간단하게 처음 시도해볼 수 있는 방법입니다.

모듈을 나눴을 때 중요한 건 모듈 레벨에서 의존관계가 명확해야 한다는 것이죠. 애초에 adapter, application(hexagon)의 의존관계가 잘 설정되었다면 모듈로 분리해도 의존 관계가 단 방향이 됩니다.

여기서 domain까지 별도 모듈로 분리하는 방법도 있습니다만, 그냥 같은 모듈에 두고 ArchUnit같은 도구로 패키지 레벨에서 의존방향을 체크해도 좋습니다. 이러다 기능이 많아지면 core를 다시 기능별 모듈로 나눌 수 있겠죠. 다음 강의에서 다루겠지만, 이때도 feature/slice의 의존관계가 단 방향으로 유지되는 게 좋습니다.

api 어댑터를 분리하고 나면, 아마도 이후에 batch라든가, admin 등의 다른 종류의 프라이머리 어댑터 계층을 독립적인 모듈로 추가할 수 있습니다. 각각이 하나의 Spring Batch 애플리케이션이 되기 때문에 분리되는 것이 이상적입니다.

반대로 세컨더리 어댑터들은 core와 이후 분리된 슬라이스에서 공유되는 경우가 많습니다. 이것도 단계적으로 모듈로 분리할 수 있습니다. DB와 관련된 persistence, 그리고 외부 서비스와의 통합을 담당하는 integration, 또 security 등등이죠.

이후에 또 내부, 외부 연동을 위해서 더 세분화 하기도 합니다. 혹은 MSA로 확장되면 더 큰 단위로 분리가 되기도 하죠.

이후 강의에서 이런 케이스들을 계속 다뤄보겠습니다.

안녕하세요, 인프런 AI 인턴입니다. rhdrlehf5님께서 멀티 모듈 구조에 대해 질문을 주셨습니다.

멀티 모듈 구조의 이해

멀티 모듈 프로젝트에서는 각 모듈이 명확한 책임과 역할을 가지도록 하는 것이 중요합니다. 질문 주신 대로 API와 Core로 나누는 접근 방식은 일반적이며 각각의 역할에 따라 구분해보겠습니다:

1. API 모듈

   • Adapter Layer: 사용자 인터페이스 및 외부 시스템과의 통신을 처리합니다. HTTP 요청 처리, REST API 정의 등이 포함될 수 있습니다.
     

2. Core 모듈

   • Application Layer: 비즈니스 로직과 애플리케이션의 유스케이스를 정의하는 부분입니다. 이 레이어에서는 도메인 객체를 활용하여 애플리케이션의 구체적인 유스케이스를 구현합니다.
     
   • Domain Layer: 순수한 비즈니스 로직과 규칙을 포함하며, 엔터티, 값 객체, 서비스 등을 포함합니다. 다른 레이어의 변경에 영향을 받지 않도록 설계되어야 합니다.
     

모듈 구성의 타당성

현재 구성하신 방식에서도 각 모듈의 역할이 잘 분리되어 있다면 충분히 괜찮은 접근 방식입니다. 다만, 헥사고날 아키텍처의 원칙을 고려한다면 각 모듈 내에서 책임과 의존성을 잘 관리하는 것이 중요합니다.

• 외부와의 연결 및 구현 세부 사항은 Adapter 모듈이 담당하고
  
• 비즈니스 로직과 도메인 관련 작업은 Core 모듈에서 관리하면 변경이 적고 유지보수가 용이한 구조가 될 수 있습니다.
  

참고 자료

이와 관련한 기존 답변과 추가적인 예시를 보시고 싶으시다면 다음 링크를 참고하세요:

• “헥사고날 아키텍처와 DDD를 활용한 멀티 모듈 구성 사례”
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.

현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.