인프런 커뮤니티 질문&답변
작성한 질문수
멀티 모듈 구성
작성
·
125
0
안녕하세요 토비님,
우선 강의를 통해 제가 알고 있던 헥사고날과 DDD(도메인 주도 설계)에 대해 다시 한번 깊이 생각해볼 수 있는 소중한 경험이 되었습니다. 좋은 강의 만들어주셔서 정말 감사합니다.
토비님께서 생각하시는 헥사고날에, DDD 과 멀티 모듈의 바람직한 설계에 대해 궁금해서 질문을 남기게 되었습니다. 여기서의 멀티 모듈은 우선 MSA 를 제외하고 순수 멀티 모듈을 통해 시스템을 설계를 한다는 것을 전제하고 있습니다.
가장 흔하게 보이는 멀티 모듈 구성의 패턴은 Storage (JPA), External (외부 Dependency), N 개의 서비스에 해당하는 Web Server 모듈 & 기타 등이 있는 것 같은데요. 멀티 모듈을 현 강의에서 보여주고 말씀해주시는 헥사고날과 DDD 와 결합했을 때, 어떻게 구성하면 좋을지 많은 생각이 들고 또한 현업에서 비슷한 고민을 하고 있어서 토비님의 생각이 궁금해 질문을 남기게 되었습니다.
감사합니다.
답변 2
3
안녕하세요. 말씀하신 멀티 모듈은 스프링 부트 애플리케이션 단위로 조합이 되는 주로, 기술에 의한 Gradle 멀티 모듈인 것 같네요. 이 외에도 도메인을 다시 관심사에 따라 여러 개의 모듈로 구분하는 방법도 있습니다.
이건 DDD, 헥사고날과 상관없이 빌드 구조에 따라 여러 개의 모듈로 구분이 되는데, 그 방식도 Gradle 모듈 단위의 멀티 모듈부터 마이크로 서비스까지 여러가지 접근 방법이 있고, 각각이 가지는 장단점과 접근 방법을 선택하는 이유는 꽤 여러가지를 들 수 있습니다.
그래서 어떤 멀티모듈 구성이 좋은지에 대해서 어떤 것이 좋다라는 답을 드릴 수 없습니다.
클린 스프링 강의 시리즈 세 번째 주제에서 바로 이 부분을 다룰 생각입니다. 지금은 하나로 되어있는 Gradle 모듈을 여러개로 나누면서 모듈을 구성하는 여러가지 방법을 살펴보고, 그 중 한가지 선택을 해보고 여러가지 특징과 장단점, 트레이드 오프 등을 이야기 해보려고 합니다.
다시 말씀드리지만 어떤 경우에도 잘 맞는 이상적인 멀티 모듈 구성법이란 세상에 존재하지 않습니다. 경우에 따라 다릅니다. 중요한 건 어떤 선택을 했을 때 어떤 이유를 가지고 접근할 것인지, 그걸로 얻게 되는 이익은 무엇이고, 반대로 손해는 어떤 것이 있는지 트레이드오프를 따져보는 기회를 가져보려고 합니다.
저도 지금 당장 속시원한 해법을 드릴 수 없어서 아쉽습니다. 어쩔 수가 없네요. 조금만 더 기다려주시면 이 부분에 대해서 깊이 이야기해보는 강의를 준비해 보겠습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 정광근님이 멀티 모듈 구성에 대해 질문해주셔서 감사드립니다. 헥사고날 아키텍처와 DDD를 멀티 모듈 시스템에 적용하는 것은 상당히 흥미로운 주제입니다.
멀티 모듈과 헥사고날 아키텍처, DDD의 통합
헥사고날 아키텍처는 시스템을 내부 도메인 로직과 외부 환경으로 명확히 분리하여 유연성과 테스트 용이성을 높이는 아키텍처 패턴입니다. 이를 멀티 모듈 시스템과 결합할 때, 핵심은 각 모듈이 자신의 책임에 맞게 구조화되어 있어야 한다는 것입니다.
일반적인 멀티 모듈 구성 방식
Core 모듈:
- 도메인 로직 및 핵심 비즈니스 로직을 포함합니다. 헥사고날 아키텍처의 중심으로, 외부 환경에 의존하지 않도록 설계합니다.
- 도메인 로직 및 핵심 비즈니스 로직을 포함합니다. 헥사고날 아키텍처의 중심으로, 외부 환경에 의존하지 않도록 설계합니다.
Infrastructure 모듈:
- JPA를 포함한 데이터 저장소, 메시징, 외부 API 호출 등을 처리합니다. 이 모듈은 외부 환경에 대한 구체적인 구현 세부 사항을 포함하므로, 도메인 모듈을 직접 참조하지 않도록 주의합니다.
- JPA를 포함한 데이터 저장소, 메시징, 외부 API 호출 등을 처리합니다. 이 모듈은 외부 환경에 대한 구체적인 구현 세부 사항을 포함하므로, 도메인 모듈을 직접 참조하지 않도록 주의합니다.
Application 모듈:
- Use case를 수행하고 도메인 객체와 Infrastructure 간의 경계를 관리합니다.
- Use case를 수행하고 도메인 객체와 Infrastructure 간의 경계를 관리합니다.
Interface Adapters 모듈:
- 사용자 인터페이스와 API 요청을 처리하며, 웹 서버 관련 기능을 제공합니다. 이 모듈도 외부와의 상호작용을 처리하는 데 초점을 맞춥니다.
- 사용자 인터페이스와 API 요청을 처리하며, 웹 서버 관련 기능을 제공합니다. 이 모듈도 외부와의 상호작용을 처리하는 데 초점을 맞춥니다.
DDD 관점에서의 고려사항
모듈 간 통신:
- 모듈 간 통신은 명확한 경계를 유지하면서 헥사고날 아키텍처의 규칙을 따르는 것이 중요합니다. 각 모듈이 특정 도메인 논리를 가져서는 안 되며, Service 계층을 통해 간접적으로만 접근해야 합니다.
- 모듈 간 통신은 명확한 경계를 유지하면서 헥사고날 아키텍처의 규칙을 따르는 것이 중요합니다. 각 모듈이 특정 도메인 논리를 가져서는 안 되며, Service 계층을 통해 간접적으로만 접근해야 합니다.
보편 언어:
- DDD의 핵심 원칙 중 하나인 보편 언어(Ubiquitous Language)를 모든 모듈에서 동일하게 적용하여 조직 내에서 의사소통의 일관성을 유지합니다.
- DDD의 핵심 원칙 중 하나인 보편 언어(Ubiquitous Language)를 모든 모듈에서 동일하게 적용하여 조직 내에서 의사소통의 일관성을 유지합니다.
독립성 보장:
- 모듈 각각이 독립적으로 개발되고 배포될 수 있도록 설계해야 합니다. 이러한 독립성은 지속적인 개발 속도를 높이고 종속성을 최소화하는 데 기여합니다.
- 모듈 각각이 독립적으로 개발되고 배포될 수 있도록 설계해야 합니다. 이러한 독립성은 지속적인 개발 속도를 높이고 종속성을 최소화하는 데 기여합니다.
관련 콘텐츠
이와 관련하여 기존의 답변이 담고 있는 사례는 다소 부족할 수 있지만 관련된 개념을 더 깊이 이해하고 싶다면 다음의 자료를 참고해주시면 좋을 것 같습니다:
제가 제공해드린 링크들을 통해 다양한 사례와 구체적인 코드 예제를 확인해보시길 추천드립니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.