먼저 User Entity 하위의 Entity인 Driver의 필드값을 계산해야 하는데 계산을 편하게 하려면 Driver의 Repository가 있으면 좋은 상황이었다.
그래서 튜터님께 질문을 드렸다.
남예준(단기심화 Java_4기)
안녕하세요 튜터님! 3조 남예준이라고 합니다.다름이 아니라 여쭤보고 싶은 게 있어서 메시지를 남기게 됐습니다.제가 고민하고 있는 부분은 User와 Driver 엔터티가 하나의 애그리거트로 묶여 있고 User가 애그리거트 루트인 상황에서 벌어졌습니다. Driver 엔터티가 order라는 배달 순번이라는 컬럼을 가지고 있는데 Driver의 소속 id 값으로 조회하고 max + 1을 통해 order 순번을 정할 생각이었습니다. 그런데 Driver에 대한 Repository를 만들어야 해당 문제가 해결이 될 거 같은 기분이 들었습니다.이게 애그리거트 루트가 아니어도 Repository가 생겨도 괜찮은가요? 아니면 아예 애그리거트를 분리해야 했던 걸까요?감사합니다 튜터님 (편집됨)
:최고:1
5개의 댓글
서동우(단기심화_튜터)
네, 예준님 안녕하세요 ㅎㅎ ~!!깊이 있는 질문인 것 같습니다 예준님 ㅎㅎ현재 User와 Driver를 하나의 애그리거트로 묶은 설계는, 아마도 배송 관리 기능을 User 중심으로 표현하기 위해 선택하신 것으로 보입니다.하지만 이렇게 구성하면 Driver에 대한 조회나 변경이 모두 User 애그리거트를 통해서만 이루어지게 되고 (UserRepository 로 조회 해야 함)그러나 Driver는 독립적으로 조회되고 변경될 수 있는 도메인 개체라는 점에서, 이는 Driver를 User 애그리거트에서 분리해야 할 신호로 볼 수 있습니다.즉,
- Driver의 생명주기나 관리가 User에 종속되지 않고
- Driver가 자체적인 도메인 규칙과 행위를 가질 수 있다면
Driver를 별도의 애그리거트로 구성하는 것이 더 적절한 모델링 방향으로 보실 수 있습니다. (편집됨)
남예준(단기심화 Java_4기)
감사합니다!!! 별도의 애그리거트로 분리하는 것 외에 UserRepository에서 native query 등을 사용하는 것도 비추천하시는 방식이라고 생각하면 될까요?
서동우(단기심화_튜터)
아 네 예준님,해당 부분이 비추천 되거나 잘못 되었다기 보다는 단순 읽기의 경우는 그렇게 사용하셔도 크게 문제 없습니다. 다만, 변경의 관련된 부분은 User를 통해 접근을 해주시는 것이 좋습니다. (데이터의 일관성 문제 때문)한 번 새로운 애그리거트로의 분리가 현재 상황에서 타당한지 따져보시고, 혹시 Driver에 변경이 필요하다면 이를 User 엔티티를 통해 이루어지게 할 수 없을지, 등등을 고려하셔서 결정해주셔도 될 것 같습니다 ㅎㅎ !! (편집됨)
👍1
남예준(단기심화 Java_4기)
너무나도 감사드립니다! 충분히 고민해 본 후 좋은 결정 내리겠습니다!좋은 하루 보내세요!
서동우(단기심화_튜터)
네 예준님 !! ㅎㅎ 한 번 고민해보시고 궁금하신 것 생기시면 방문해주세요 ㅎㅎ 🙂
결론적으로는 다른 애그리거트로 분리하기 애매한 느낌이라 조회만 하는 경우에는 native query를 사용해서 하는 방법이 괜찮을 것 같아 선택해서 개발을 진행했다.
