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

안녕하세요! 질문 감사합니다!
고민을 많이하시면서 강의를 아주 잘 활용하고 계시군요! 멋집니다! 👍

제 생각 기준으로 말씀드려보면!

리뷰의 대상이 OrderItem이라고 표현 하는 것은 개념적으로 맞지 않다고 생각합니다
(물론 Review 가 Order 개념을 이미 알고 있는 형태의 개념도는 맞지만 이는 ReviewPolicyValidator에서 orderItem 을 활용하고 있기 때문에 나온 부분입니다)
핵심적으로 정리하면 리뷰가 OrderItem에 작성 될 수 있는 것은 정책적인 부분이라고 생각합니다

추후에 리뷰 작성 정책이 변경 되거나 배송이나 다른 기준이 생긴다던가 등등 정책적인 변경에 영향이 간다고 보여집니다, 고로 개념적으로 연관 되어 있다고 보기는 어려울 것 같습니다

또한 엄밀히 말하면 논리적으론 Review는 Product 를 약하게는 알고 있습니다 ReviewTargetType 자체가 Product 를 지칭해버리고 있죠

reviewKey 필드에 orderItem 의 id 가 조합해서 들어가지만 이건 단순 문자열의 조합일 뿐이라고 봅니다 (prefix 문자열 또한 OI_*, POLICY_* 등등으로 쓸수도있지만 가독성을위해 풀어둔 상태구요!)

그래서 저는 Review의 대상은 Type 과 Id 가 존재한다면 누구나 될 수 있다 가 맞다고 봅니다

주문한 정보은 현재 정책 기준 리뷰 작성의 필수 조건 일뿐 리뷰의 대상이라고 생각하지는 않습니다

기획팀 등 누군가와 대화를 가정하여 "상품에 리뷰를 쓸텐데 왜 리뷰 개념이 상품 개념과 연결되지 않나요?"라는 질문을 받았을 때 "리뷰 대상을 범용적으로 지정하도록 설계해 상품 개념을 직접 의존하지 않기 때문"이라 대답하면 코드/스키마 관점의 대답이라 생각됩니다.

이 부분은 아주 좋은 접근입니다! (회사에서 이런 질문을 받을 수 있으면 좋겠네요ㅎㅎ)

이 관점에서 개념도를 다루는 전략의 확정이 필요합니다

위에 언급했던 것 처럼 Review는 엄밀하게는 Product 를 알고 있습니다.
다만 여기서 우리가 장기적으로 리뷰 시스템을 범용성 있게 만들어서 추후 셀러 리뷰, 배송 리뷰, 브랜드 리뷰 생길 수 있다, 장기적으로 더 나아가 리뷰 시스템을 별도의 플랫폼화 할 가능성이 있다 (이것은 코드/스키마적 관점은 아님) 라는 합의가 있었다면 자연스러운 개념도가 된다고 봅니다.
(다만 여기서 "지금 우리 상황에서 굳이 그렇게까지요??? 그거 언제할건데요?;; 우리 개발자 셋인데요?" 라고 생각해봐야한다고 봅니다ㅎㅎㅎ 그런 생각이 나시도록 의도하긴 했습니다ㅎㅎㅎ)

그러므로 전사적은 아니더라도 관련자들은 충분히 인지해야하는 부분이라고 봅니다
(그리고 오히려 저렇게 훌륭하게 물어봐 주면, 자연스럽게 우리 서비스의 성장 방향성을 다운로드 해줄 수 있기 때문에 이 기준대로 작성하는게 좋다고 봅니다)

만약 그런 합의가 없거나 관심이 없어서 적어주신대로의 혼란이 있을 수 있다면 더 작은 점선 or 연한 점선(그 만큼 연관성이 얕다는 것을 표현) 하는 식으로 표현할 수 있을 것 같습니다

다만 문제는 그렇게 되면 개념도가 너무 복잡해집니다, Review 작성 대상이 많아지면 많아질 수록 화살표들의 복잡하게 연결되고 복잡해 보일 것 같습니다, 그래서 필요하다면 별개로 느슨한 연관 개념도 or 리뷰 상세 개념도 같은 것을 그리는게 낫지 않나 싶긴합니다
(물론 현재 우리 상황에선 그렇지 않긴합니다ㅎㅎ)

참고로 제가 말한 것 또한 현재 강의 예제 상황에 맞춘 제 기준에 의한 생각입니다 😃
생각하시는데 참고가 되었길 바랍니다!

아무튼 강의를 아주 잘 느끼시고 고민하시는 것 같아서 너무 뿌듯합니다! 완강까지 화이팅이고 완강 수강평 기대하고 있겠습니다!!

모쪼록 답이 되었길 바랍니다! 감사합니다!

안녕하세요, 인프런 AI 인턴입니다. 백엔드해야지님.

강의에서 다루신 개념도와 관련하여 깊이 있는 질문을 주셔서 감사합니다. 개념도에서의 각 요소는 비즈니스 요구사항을 기반으로 서로 어떻게 연결되고 상호작용하는지를 설명하는 중요한 역할을 합니다. 여기서 중요한 점은 비즈니스 관점에서의 연결성과 개념이 어떻게 배치되어야 하는지를 깊이 있게 이해하는 것입니다.

질문에 대한 간단한 요약과 설명:

1. 리뷰와 상품의 연결:

   • 리뷰가 비즈니스적으로 ‘상품’에 대한 것이라는 점에 동의하시는 것 같습니다. 하지만, 강의에서 제시된 대로 리뷰는 ‘구매한 상품(OrderItem)‘에 대한 평가임을 강조합니다. 이처럼 리뷰가 구체적으로 구매한 상품을 대상으로 작성되기 때문에 개념도에서 상품(Product)이 아닌 주문(Order)이 강조된 것입니다.
     

2. 개념도에서의 의존성 표현:

   • Review와 OrderItem의 직접적인 연결은 구매 후의 피드백이라는 비즈니스 개념을 반영하고 있으며, Product를 간접적으로 참조하는 구조로 보입니다. 이는 OrderItem을 통해 충분히 상품에 대한 정보를 포함하고 있음을 의미합니다.
     

3. ‘리뷰 대상의 범용적 설계’ 관점:

   • 강의에서 언급된 ‘리뷰 대상의 범용적 설계’는 추후 다양한 리뷰 대상을 포함할 수 있는 확장성을 고려한 것입니다. 이는 객체 설계에서 자주 사용되는 일반화 접근 방식으로, 특정 대상(ex. 상품) 뿐만 아니라 다른 대상에도 유연하게 적용할 수 있는 구조입니다. 하지만, 여러분이 언급하신 대로 이 점은 코드 및 스키마 관점에서 이야기를 하게 될 가능성이 높습니다.
     

위의 설명을 통해, 개념도가 어떻게 비즈니스 목적에 맞게 설계되었는지를 이해하셨기를 바랍니다. 매개된 연결 구조가 실제로 비즈니스 로직을 해석하고 전달하는 데 중요한 부분을 차지하게 됩니다. 질문에 대한 이해를 돕기 위해 관련된 추가 질문과 기존 답변을 참고하는 것도 좋습니다.

1. 상위 도메인과 하위 도메인 상호 작용: 이 게시물에서는 각각의 도메인 간의 상호작용과 개념도 구성에 관한 다양한 예시를 접할 수 있습니다.
   

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

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