ReviewPolicyValidator와 ReviewManger내의 if문

Question

안녕하세요! 최근에 강의를 듣는중 궁금정이 있어 질문을 드리게되었습니다. 다름이 아니라 ReviewPolicyValidator가 있는데, ReviewManager의 update내부에서 // 기존 리뷰 이미지 불러오기 val existingImages = reviewImageRepository.findByReviewIdAndStatus(reviewId, EntityStatus.ACTIVE) // 지정된 이미지 삭제 if (imageHandle.hasImagesToDelete()) { existingImages.filter { it.id in imageHandle.deleteImageIds } .forEach { it.delete() } } // 기존에 이미지가 있었는데 삭제 후 남은 이미지도 없고 새로운 이미지도 없으면 에러 if (existingImages.size > 0 && existingImages.count { it.isActive() } <= 0 && imageHandle.hasImagesToAdd() == false) { throw CoreException(ErrorType.REVIEW_CANNOT_DELETE_ALL_IMAGES) } 요런식의 예외처리가 있더라고요, 제가 생각하기에는 이것또한 하나의 정책의 범주에 들어간다고 생각되는데, 해당 부분이 PolicyValidator가 아닌 Manager에 남게된 이유가 무엇일까요? 개인적인 생각으로는 delete처리가 들어가기전에 filtering으로도 충분히 알 수 있을것 같은데 filter 연산을 한 번 더 해야되는것 때문에 그런가 싶기도하고... ReviewPolicy이지 ReviewImagePolicy가 아니여서 그런가? 싶기도 하고... 혼자서는 도저히 결론을 내지 못하겠어서 도움을 청하게 되었습니다 ㅠㅠ 늘 좋은 강의 정말 감사드리고, 추석 잘 보내세요!

제미니 · Answer

안녕하세요 질문 감사드립니다 해당 부분은 개념들의 전파 기준을 어디까지 가져갈지 + 로직 응집에 대한 전략 결정이 필요한 부분입니다. ReviewPolicyValidator 에 이미지 삭제에 대한 로직이 들어가게 되면 imageHandle이 전달되어야합니다 그리고 자연스레 reviewImageRepository 에 대해서도 알아야하겠죠, 이런 부분을 어디까지 통제할 것 인가에 대한 결정이 필요한 것입니다 더 나아가서 지금은 ReviewService 에 reviewPolicyValidator -> reviewManager 흐름이지만 장기적으로 중간에 어떠한 로직이 추가 될 수 있을텐데요, 이때 imageHandle 이 오염될 가능성도 있을 것 같습니다 (일반적인 경우는 아닐 것 같습니다만, 신고 리뷰, 제제 리뷰 등등.. 삭제 불가한 경우라던가에 대한 상상입니다) 그럴 경우 validate 와 update 사이가 점점 멀어지게 되고, 그러다보면 검증과 실행이 차이가 있는 문제가 생길 수도 있을 것 같습니다 그치만 그것 때문에 manager에 검증 로직이 있는게 타당해지지는 않습니다. 결론적으로는 우리가 개념들을 어떻게 핸들링하고 어떻게 경계를 지을지가 핵심이라고 생각합니다 그런 의미에서 지금 기준으론 reviewPolicyValidator에 있어도 무방하다고 생각합니다 지금 Manager에 해당 예외처리가 남아있는 이유는 실제 행위 로직과의 응집도 를 지키지 위함이라고 이해해주시면 좋을 것 같습니다. 추가로 ReviewPolicyValidator.validateUpdate 의 역할은 정의 된 리뷰 업데이트 정책을 준수 했는지 검증 하는 것 입니다 그 관점에서 이미에 대한 것은 리뷰 업데이트 정책 보다는 리뷰 업데이트 중 발생하는 상태 에 가까운 것 같다는 생각도 듭니다 그래서 정답은 없으니 여러 방향으로 고민해보시면서 개념과 컴포넌트들의 형태를 고민해보시면 좋을 것 같습니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 이준규님! 질문하신 ReviewManager.update() 내부의 이미지 삭제 검증은 정책에 해당할 수 있지만 , 반드시 ReviewPolicyValidator 에서 처리해야 하는 것은 아닙니다. 일반적으로 ReviewPolicyValidator 는 여러 도메인 객체나 외부 데이터를 조회해야 하는 독립적이고 복합적인 정책 검증 을 담당합니다. 반면 해당 if 문은 ReviewManager.update() 과정에서 이미 계산된 existingImages , imageHandle 을 바탕으로 리뷰 이미지 변경 작업의 최종 상태를 검증하는 로직 입니다. 즉, 다음과 같이 책임을 나눌 수 있습니다. ReviewPolicyValidator : 리뷰 작성·수정 가능 여부, 주문 상품이나 작성자 등 외부 데이터가 필요한 정책 검증 ReviewManager : 이미지 추가·삭제라는 변경 작업을 조합하고, 변경 결과가 유효한지 확인하는 검증 따라서 이 로직을 ReviewPolicyValidator 로 옮길 수도 있지만, 그러려면 Validator가 이미지 변경 전후 상태나 imageHandle 같은 정보를 인자로 받아야 합니다. 현재 구조에서는 이미지 변경 흐름을 가장 잘 알고 있는 ReviewManager 에 두는 편이 응집도 측면에서 자연스러울 수 있습니다. 검증 로직을 어디에 둘지에 대한 유사한 논의는 아래 질문을 참고해 보시면 좋습니다. 개념을 나타내는 객체 내에 로직이 들어있는 것은 좋지 않을까요? 검증 대상이 객체 자체의 상태인지, 여러 객체나 외부 데이터까지 필요한 복합 정책인지에 따라 책임을 나누는 관점을 설명하고 있습니다. 데이터 검증 로직 책임에 대한 질문이 있습니다. 요청 검증과 개념 객체·비즈니스 로직 검증을 어떤 기준으로 분리할지에 대한 답변을 참고할 수 있습니다. 결론적으로 해당 if 문도 넓은 의미에서는 정책이지만, 정책이라는 이유만으로 항상 PolicyValidator로 분리해야 하는 것은 아닙니다. 이미지 변경 과정 자체에 밀접하게 결합되어 있고 Manager가 이미 필요한 정보를 가지고 있다면 Manager에 두는 것이 타당합니다. 반대로 여러 곳에서 재사용되거나 독립적인 정책으로 커진다면 ReviewPolicyValidator 의 메서드로 추출하는 것을 고려할 수 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.