review_stats 도메인에 관한 질문

[newnyee]

밥도둑 프로젝트의 구조상 review_stats 엔티티는 어디에 두는것이 맞을까요?

1. reviews 도메인
2. restaurants 도메인
3. reviews와 restaurants 도메인을 나누지 않고 restaurants 도메인만 두고 그 안에서 review, reviews, restaurants 엔티티를 다 관리하자

[buhee1029]

테이블의 사용에 기준을 둔다면 식당 도메인에 두는게 맞을 것 같고, 삽입 기준으로 본다면 리뷰 도메인에 두는것이 맞을것 같긴한데 고민이 되네요!!

[kmss6905]

식당과 리뷰는 함께 생성되거나 변경되는 게 아니고 변경주체도 다르니까 다른 도메인으로 보는 게 맞지 않을까요?

가령 리뷰의 생성,수정,추가는 사실 식당의 생성,수정,추가와는 관련이 없음에도 불구하고 식당 도메인을 통해 들어가서 수정하는 느낌?
어떻게 보느냐의 차이인 것 같아요!

[min050410]

저도 의견 남기겠습니다 ㅎㅎ

일단 처음으로 Review와 Review stat 엔티티는 Bounded Context 원칙을 적용한 것이기 때문에
일단 두개의 엔티티는 같은 도메인 상에 있어야 한다고 생각합니다!

저번에 저희가 작업했던 Feed와 HashTag의 경우에는 완전히 종속되어 있었습니다.
이번 프로젝트의 경우에도, Restaurant과 Review는 종속되어 있습니다.
Review의 이름이 Restaurant-Review로 바뀌어도 별 위화감이 없다는 것은 종속되어 있다는 증거입니다.
리뷰가 "레스토랑"의 리뷰이기 때문이지요.

그렇기 때문에 개인적으로 Restaurant 도메인 안에 Review 엔티티를 둘 것 같습니다. 😄
만약에 Review가 다른 리뷰에도 쓸 수 있다면 그때엔 리뷰 도메인을 분리했을 것 같네요 ex) 당근마켓 매너 온도 리뷰

[newnyee]

동의하옵니다

[kmss6905]

당근마켓 매너 온도 리뷰를 생각하니까 어떤 느낌인 지 이해했습니다 😄 👍

추가로 나중에 저희가 생각하는 '도메인' 이 무엇인지를 서로 이야기 해보면 좋을 것 같습니다!

[buhee1029]

저도 게시글과 댓글로 예시를 둔 것과 마찬가지로 리뷰가 식당의 리뷰이기 때문에 영민님 말씀대로 식당 도메인 안에 넣는 것도 좋다고 생각됩니다!

[hsjkdss228]

저도 영민님의 의견처럼 Review가 어떤 다른 도메인들에서 공통으로 사용되는 것이 아니라 Restaurant에 종속되어 있기 때문에 Restaurant 패키지와 같은 레벨에서 관리되는 게 맞을 것 같다는 의견입니다.

아예 한술 더 나가서 테이블이나 엔티티 이름에서도 restaurant_reviews, RestaurantReview로 의미를 드러내면 더 나을 수도 있을까?하는 생각까지도 해봅니다.

결론은 저는 3번에 한 표!

[newnyee]

좋은 의견 주셔서 감사합니다! 3번으로 반영하겠습니다😁
현재 프로젝트에 반영해주시고 계신 @buhee1029 님 감사드립니다😄