required 포트에 관해서

토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1

작성

수정됨

안녕하세요 토비님

현재 파트1에서는 아직 required 포트에있는 repository 인터페이스를 다른 도메인에서 사용하고 있지 않아서 중복이 발생하고 있지 않지만, 만약 다른 도메인에서도 같은 리포지토리를 사용해야할 경우 어떻게 하면 좋을지 질문드립니다. 제가 생각한건 첨부한 이미지와 같습니다.

도메인별로 각각 required 포트에 MemberFinder 인터페이스를 선언하고 그것을 Adapter layer에서 각각 도메인 별로 구현합니다. 하지만 실제 로직은 Adapter레이어에 있는 MemberRepository를 부르는 역할만 할 뿐입니다

java spring spring-boot jpa 리팩터링 ddd

답변 2

토비

지식공유자

리포지토리처럼 DIP가 적용된 경우에 이 인터페이스는 이를 사용하는 쪽 모듈에 가까이 두는 것이 중요합니다. 여기서는 헥사곤 내부에 두었지요. 그런데 그 중에서 여러 모듈에서 사용하게 되는 것들이 있습니다. 외부 연동용 API도 그렇고요. 보안쪽도 그럴 수 있죠. 또 조회용 리포지토리도 많은 경우 그에 해당됩니다.

이 때 두가지 접근방법을 둘 수 있습니다. 여러 모듈에서 사용되는 required interface에 해당되는 리포지토리를 shared 모듈을 별도로 만들어서 그 안에 두는 방법입니다. 이러면 어떤 모듈에서든 자유롭게 사용해도 되고, 의존 방향도 단방향으로 적절하게 구성할 수 있습니다. 다만, 도메인의 엔티티가 파라미터나 리턴 값으로 사용되고 있다는 점에서 리포지토리를 메인 엔티티가 존재하는 모듈 외부로 가져오는 것이 적절한지는 의문이기도 합니다.

그래서 두번째 방법으로 헥사고날 애플리케이션 모듈의 의존 방향이 꼬이지 않는다면, 즉 양방향 참조가 일어나지 않는다면 다른 모듈의 리포지토리는 필요에 따라서 사용하는 것을 허용하는 것입니다. 이때는 반드시 조회 기능에 제한을 두어야 합니다. 다른 모듈에서 수정까지 일으키면 의존관계가 얽혀서 나중에 이해하기 힘든 코드가 되버리겠죠.

Team -> Member 의존 구조로 정의한다면 Team 애플리케이션 쪽에서는 Member의 provided interface를 태우지 않고, 바로 MemberRepository(여기서는 Finder라고 하셨네요)에 접근하는 것까지 허용하는 것입니다. 하지만 반대는 만들지 않는 것이 좋습니다. Member에서 Team에 접근해야 하는 상황이라면 도메인쪽 설계를 다시 고민해보거나, 여기서 모듈간에 DIP를 다시 쓰는 방법이 있습니다.

인프런 AI 인턴

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

repository 인터페이스를 여러 도메인에서 사용하는 경우, 중복을 어떻게 관리할지에 대한 고민은 매우 중요한 설계 이슈 중 하나입니다. 말씀하신 이미지에서 볼 수 있듯이, 각각의 도메인에 해당하는 required 포트가 필요할 때, 여러 도메인에서 동일한 기능을 제공하는 인터페이스를 효과적으로 관리하는 방법에 대해 고민하신 것 같습니다.

접근 방법

통일된 인터페이스 사용: 여러 도메인에서 동일한 리포지토리를 사용할 경우, 공통된 인터페이스를 정의하고 각 도메인에서 이를 구현하도록 설정할 수 있습니다. 이는 각 도메인에서 중복된 구조를 피하면서 재사용성을 높일 수 있는 방법입니다.
도메인별 인터페이스 분리: 각 도메인의 요구사항이 미묘하게 차이가 있는 경우, 각 도메인에 맞게 인터페이스를 분리할 수 있습니다. 이후 어댑터 계층에서 이 인터페이스들 각각에 대한 구현체를 작성하여, 도메인별 특수성을 반영할 수 있습니다. 이렇게 되면 각 도메인에서 개별적으로 인터페이스를 관리하지만, 실제 구현은 재사용될 수 있습니다.
공통 인터페이스 확장: 도메인 간에 많은 유사성이 있다면, 공통 인터페이스를 두고 특정 도메인별 인터페이스가 이를 확장하도록 할 수 있습니다. 이를 통해 공통적인 부분은 유지하면서도 도메인 특수성을 추가할 수 있습니다.

추가 팁

철저히 프로젝트의 요구사항에 맞게 설계해야 하며, 상속이나 인터페이스 확장에서 발생할 수 있는 복잡성을 신중히 고려해야 합니다.
헥사고날 아키텍처의 철학에 따라, 외부와의 의존성을 최소화하고, 도메인 모델의 독립성을 유지하는 것이 매우 중요합니다. 이를 통해 언제든지 도메인 로직을 쉽게 변경할 수 있도록 설계할 수 있습니다.

기존 인프런 Q&A에서 비슷한 주제를 다룬 예시를 볼 수 있습니다. 이는 조금 더 구체적인 설계 방향을 잡는 데 도움이 될 수 있습니다:

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

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

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