InvalidCurriculumException DIP 적용 여부 문의

작성한 질문수 1

0

날카로운 지적을 해주셨네요.

말씀하신 대로 지금 구현에서는 예외 클래스 때문에 양방향 의존성이 남아있게 되네요. 현재 ArchUnit에서는 애플리케이션 컴포넌트 레벨에서 순환참조 확인이 안 되고 있었습니다. 도메인과 애플리케이션 계층에서 각각 체크하기만 해서 이 부분을 놓치고 있었네요.

ValidationException은 shared 모듈에 정의를 해둔 것이 있으니 그걸 인터페이스에서 던지도록 정의해두고, CurriculumValidationException이 발생하는 CurriculumModifyService 클래스 내 validate() 구현 내부에서 이를 캐치해서 ValidationException으로 한번 wrapping해서 던지게 하면 됩니다.

제가 미처 체크하지 못했던 부분을 알려주셔서 감사합니다. 피드백 반영할 때 이 내용도 추가하도록 하겠습니다.

0

안녕하세요, 인프런 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를 통해 의존관계를 역전하는 방법을 설명하고 있습니다.

• 어플리케이션 , 도메인 계층질문
  도메인 계층의 구체적인 로직과 애플리케이션 계층의 추상화 및 오케스트레이션을 어떻게 구분할지에 대한 답변입니다.

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