InvalidCurriculumException DIP 적용 여부 문의

Question

안녕하세요. 토비님

DIP와 관련하여 질문이 있습니다.

"course" 컴포넌트 <- "curriculum" 컴포넌트는
단방향 의존성을 가져야하기 때문에, CurriculumValidator.class를 DIP를 통해 course 패키지로 옮긴 것을 이해하였습니다.

하지만, CurriculumValidator에서 던지는 예외인 InvalidCurriculumException.class는 "curriculum" 도메인에 속해 있습니다.

이것은 결국 양방향 의존성을 가지게 되는 것 아닌가요?

만약, 양방향 의존성이 맞다면,
CurriculumValidator 인터페이스는 ValidationException을 던지도록 선언하고,
CurriculumValidator인터페이스 구현체인
"CurriculumModifyService.class"는 "InvalidCurriculumException" 을 catch해서 ValidationException을 던지도록 수정하는 방법도 괜찮을까요?

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 이주엽님! 질문하신 구조에서 CurriculumValidator 인터페이스가 course 컴포넌트에 있고, 해당 인터페이스가 curriculum 도메인의 InvalidCurriculumException 을 참조한다면 course -> curriculum 의존성이 추가됩니다. 이미 curriculum -> course 의존성이 존재한다면 컴포넌트 간 양방향 의존성이 만들어질 수 있습니다. 따라서 예외 타입도 의존성 방향을 고려해야 합니다. 선택지는 다음과 같습니다. InvalidCurriculumException 을 course 컴포넌트가 알아야 하는 계약으로 볼 수 있다면, 예외를 course 쪽으로 이동 course 가 curriculum 의 구체적인 실패 사유를 알 필요가 없다면, course 에 ValidationException 과 같은 추상적인 예외 또는 검증 결과를 정의 curriculum 의 구현체에서 InvalidCurriculumException 을 잡아 ValidationException 으로 변환 질문하신 것처럼 인터페이스에는 ValidationException 만 노출하고, CurriculumModifyService 에서 InvalidCurriculumException 을 변환하는 방식은 의존성 방향을 단방향으로 유지하는 방법이 될 수 있습니다. 다만 단순히 예외를 감싸는 것보다, course 가 정말 예외 타입을 통해 검증 실패를 처리해야 하는지 먼저 확인하는 것이 좋습니다. 검증 결과를 반환하는 방식이 더 적절할 수도 있습니다. 핵심은 InvalidCurriculumException 이 어느 컴포넌트의 책임에 속하는지입니다. curriculum 내부에서만 의미가 있는 도메인 예외라면 다른 컴포넌트의 인터페이스에 노출하지 않는 편이 좋습니다. 반대로 여러 컴포넌트가 공통으로 이해해야 하는 비즈니스 규칙이라면 공통 계약이나 상위 컴포넌트에 추상화할 수 있습니다. 관련해서 컴포넌트 사이의 순환 의존성과 DIP 적용 방법은 아래 답변을 참고해 보시면 좋습니다. 같은 계층에서의 의존성 관리 질문 애플리케이션이나 애그리거트가 달라지는 경우 의존 관계를 단방향으로 조절하고, 양방향 참조가 필요하다면 설계를 변경하거나 DIP를 통해 의존관계를 역전하는 방법을 설명하고 있습니다. 어플리케이션 , 도메인 계층질문 도메인 계층의 구체적인 로직과 애플리케이션 계층의 추상화 및 오케스트레이션을 어떻게 구분할지에 대한 답변입니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.