엔티티 설계 질문

늦은 시간에 이렇게 성의있고 친절한 답변을 달아주시다니 정말 감사하고 감동입니다!
항상 도메인을 설계하면서 어그리게잇 범위에 대해서 고민해왔습니다. 그리고 여러 엔티티에 어그리게잇 루트 레포지토리 하나만 있어야한다는 강박도 어느정도 있었구요ㅜㅜ
주변에 물어볼 사람도 없었는데 강사님께서 설계시 요즘의 방향에 대해서 말씀해주셔서 앞으로의 설계에도 큰 도움이 될 것 같습니다.

감사합니다!

안녕하세요. wxxsox lee님 좋은 질문입니다^^

우선 글 내용으로 추즉해보건데, Parent -> Child를 @OneToMany 단방향으로 설계하신 것 같아요.

일대다 단방향 매핑을 할 때는 주의할 점들이 있는데, Parent, Child간에 연관관계 매핑을 어떤 식으로 했는지 자세하게 코드 레벨로 매핑 어노테이션을 포함해서 적어주시면 더 많은 도움을 드릴  수 있을 것 같아요^^

그럼 본론으로 들어가서 Parent Child가 정말 한 애그리게잇으로 설계되어야 하는가에 대해서 근본적인 의문을 품는 것이 필요합니다.

이미 페치 조인의 방향을 바꾸어서 조회하는 고민을 시작하게 되면, 조회의 기준점이 Parent가 아니라 Child가 됩니다. 이렇다는 것은 많은 경우 Child도 별도의 애그리게잇이 되어야 합니다.

DDD가 지금처럼 활성화 되지 않은 시점에 다들 애그리게잇의 범위를 어디까지 가져가야 하는가?에 대해서 다들 논란이 많았고, 여러 엔티티가 관계되는 거대한 애그리게잇을 생각했습니다.

하지만 막상 해보면 애그리게잇 루트가 너무 거대해지고, 더 나아가서 애그리게잇 루트를 꼭 통할 필요가 없는 경우도 많아졌습니다. 오히려 코드가 더 복잡해지는 상황이 된것이지요.

수년간의 시간이 흐르고, 지금의 방향은 대부분 애그리게잇은 매우 작은 단위, 그러니까 거의 앤티티 하나당 애그리게잇 루트가 하나가 나오는 방향으로 이야기를 많이 합니다. 그리고 그 방향에 저도 동의합니다. (상황마다 다르겠지만 애그리게잇 루트는 엔티티 하나~두게 정도에 Value Object를 몇게 가지고 있을 수 있다 정도로 이야기 합니다.)

예를 들어서 단순히 우리가 게시판과 댓글이라고 하면 게시판이 애그리게잇 루트가 되고 그 하위에 댓글이 포함 되어서 달릴 것이라고 생각하지만, 실제는 게시판과 무관하게 댓글만 조회하는 기능이 있을 수 있고, 댓글 그 자체도 별도로 조회하고, 삭제될 수 있습니다. 이런 경우라면 이미 게시판도 하나의 애그리게잇이고, 댓글도 하나의 애그리게잇으로 설계하는게 더 나은 선택입니다.

뭔가 이정도 고민이 깊은 상황이라면, 근본적으로 설계가 잘못 되었을 가능성이 높습니다. 저라면 그냥 애그리게잇을 분리하고, 그에따라 리포지토리도 분리할 것 같아요^^

감사합니다.

네 도움이 되었다니 저도 기쁘네요^^

고맙습니다