JPA책 복습하고 있는데
Order엔티티가 memberId에 대한 정보만 가지는 설계는 데이터 중심 설계라 단점이 있다.
객체지향의 장점을 사용하려면 직접 member객체와의 관계를 만들라고 하는데
제가 다음에 본 DDD 책에서는 그렇게되면 오히려 Order 도메인쪽에서 Member 메소드를 남용 할 수 있다.
Order 도메인에서 member 객체를 사용하고 싶으면, id만 보관해서 join시키던가 이벤트를 사용해서 분리시키는게 낫다 이런 내용이 있었습니다..
(정확하진 않음)
제 개인적인 생각도 굳이 Order객체가 member 객체를 알아야 할 이유가 없다고 생각합니다..
뷰에 보내는 dto처럼 다른 객체에게 어떤 데이터를 줄 때는 최대한 제한시켜서 왜 주는지 의도가 명확해야 된다고 생각하는데
Order에서 멤버 객체 자체를 활용해버리면 결합도도 높아지는 것 같고, 굳이 필요가 없는 상황에서도 너무 많은 권한이나 정보를 주는 것 같아서
저는 외래키만 가지고 있는게 낫다라고 생각합니다..
물론 장바구니, 프로덕트같은 관계면 괜찮겠지만 Order와 member간의 관계에서까지는 그렇게까지 필요하지 않다고 생각합니다..
혹시 제가 이해하고 있는 부분중에 잘못알거나 놓치고 있는 부분이 있을까요?
잘 이해하고 있네 각각 장단이 있는데, 규모가 크고 도메인간 분리가 필요할땐 ddd 책에서 말한 방식이 더 좋아 서로 엮여야한다면 애그리것을 통하는게 좋겠지 객체지향이라는게 정답이 없어
jpa 책에서는 보다 더 작은 규모의 객체지향을 이야기하다보니 외래키보다는 엔티티로 직접 매핑하는걸 선호하는거임
우리회사는 코드상 JPA 엔티티 안에 외래키는넣는데 jpa 설정에서 none 처리해서 아예 외래키가 안생기게 만듬 회사에서 개발을 하면 이런 방향이 맞는 것 같음. 괜히 DB 정합성 따져서 연관된 객체 다른 사원이 외래키 만들어서 개발 복잡도 너무 올라갈 것 같거든