하나의 레포지토리로 하위 엔티티 관리하기

프로젝트를 진행하며 애그리게잇에 대해 학습하고 고민했던 내용입니다. DDD에 관련된 내용인데 이에 대해 정확한 개념을 학습한 채 작성한 것이 아니기 때문에 잘못된 내용을 알려주신다면 보는 즉시 수정하겠습니다. **JPA를 사용했기 때문에 글을 읽기 위해서는 JPA에 대한 기본적인 이해가 필요합니다. 

 

 

2022. 10.

** 별도의 API가 필요하기 때문에 하나의 레포지토리로 하위 엔티티를 관리하는 것은 힘들다고 판단해 이 포스팅은 그 당시의 생각, 하나의 방법 정도로 읽어주시면 감사하겠습니다. 

 

 

 

 

 

1. 별도의 레포지토리가 필요할까?

---

게시판을 만들때 댓글은 게시글의 하위에 속해있습니다. 이 경우 /api/posts/{postId}/comments/{commentId} 와 같이 API를 구성할 수 있는데요, 물론 게시글과 별개로 댓글과 관련된 작업만을 하기 위해 /api/comments/{commentId} 와 같이 별도의 API를 둘 수도 있습니다. 

 

 

 

 

 

 

그런데 프로젝트를 진행하며 과연 댓글을 위한 별도의 컨트롤러가 필요할까? / 댓글의 레포지토리가 꼭 필요할까? 와 같은 의문점이 들었습니다. 댓글은 게시글에 종속적이기에 게시글을 통해 댓글을 추가/수정/삭제 할 수 있기 때문입니다. 또한 이를 통해 하나의 루트(애그리게잇)로 하위 엔티티들을 관리할 수 있게 되고 이를 통해 변경점을 줄일 수 있겠다는 생각이 들었습니다. 

 

댓글을 작성/수정/삭제하기 위해 별도의 레포지토리가 필요할까?

 

 

 

 

 

2. 애그리게잇으로 하위 엔티티 관리하기

---

위에 말했던 내용을 코드로 구현해보겠습니다. 한 가지 바뀐점이 있는데요, 위에서 말했던 게시글이 스터디로 바뀌게 됩니다. 즉 하나의 스터디에는 여러개의 댓글이 달릴 수 있고 API가 /api/study/{studyId}/comments/{commentId} 와 같이 되는 것입니다.

 

post가 study로 변경

 

 

 

 

 

이제 엔티티와 연관관계를 살펴보겠습니다. 하나의 스터디를 상세 조회하면 댓글이 함께 딸려와야 하기 때문에  Comments라는 일급 컬렉션을 만들어서 @OneToMany 관계를 설정했습니다. **조회의 편의성을 위해 @OneToMany를 맺어줬으며, Soft Delete를 구현했기 했문에 cascade는 PERSIST만 설정해줬습니다. 조회가 빈번하지 않다면 @OneToMany 관계는 굳이 맺지 않으셔도 괜찮습니다. 

 

 

 

 

 

 

본격적으로 게시글을 작성/수정하는 경우를 살펴보겠습니다. 아래는 댓글을 작성하는 경우입니다. 스터디에 댓글이 존해하기 때문에 먼저 댓글의 상위(애그리게잇)의 PK로 스터디를 조회합니다. 이후 작성할 댓글 엔티티를 생성해 찾아온 스터디 엔티티 내부의 Comments 리스트에 추가해줍니다. ** 물론 이 과정에서 스터디 엔티티를 조회하는 쿼리가 발생하게 되는데 이 부분에 대해서는 뒤에서 다루겠습니다.

 

 

 

 

 

 

댓글 생성자자와 댓글 추가로직은 아래와 같습니다. 작성한 사람을 등록하고 생성된 댓글 엔티티를 Comments내부의 리스트에 넣어줍니다.

 

 

 

 

 

 

이번엔 댓글 수정을 살펴보겠습니다. 댓글 수정도 거의 같은데 한 가지가 다릅니다. 이 경우 페치조인으로 해당 스터디가 자신과 연관된 댓글을 모두 가져와야 하는데요, 그래야 별도의 추가쿼리가 발생하지 않기 때문입니다. **fetchJoin( )은 in절로 자신과 연관된 값을 한 번에 가져오는 것을 말합니다.

 

 

 

 

 

 

이후 스터디 내부에 있는 댓글리스트에서 해당 댓글을 찾아온 후 내용을 수정해주면 됩니다. 아래 메서드는 댓글의 레포지토리가 아닌 엔티티 내부에 존재하는 댓글을 찾아오는 메서드입니다. 

 

 

 

 

 

 

 

위와같은 방법으로 별도의 댓글 컨트롤러/레포지토리 없이도 CasCade를 통해 내용을 추가/수정/삭제할 수 있습니다. 이를 통해 얻을 수 있는 점은 관리 포인트가 줄어들게 된다는 점입니다. 즉 스터디(루트 엔티티)를 통해 해당 댓글들을 관리하기 때문에 변경 포인트가 줄어들게 되는 것입니다. 기존에는 CommentController를 만들어서 별도의 api를 만들고 이를 통해 관리했지만 이제는 StudyController 하나의 엔드포인트만으로, Study 엔티티만으로 모든 하위 엔티티들을 관리할 수 있게 되었습니다. [이미지 출처]

 

루트 엔티티를 통해 작업하기 때문에 하위 엔티티끼리는 참조하지 않습니다.

 

 

 

 

3. Conclusion

---

물론 여기에 장점만 있지는 않습니다. 하위 엔티티를 작업하기 위해서는 반드시 자신의 루트(애그리게잇) PK가 필요합니다. 뿐만 아니라 해당 애그리게잇을 통해서만 모든 작업을 할 수 있기 때문에 엔티티에 많은 로직이 들어가게 되고, 엔티티 그래프 탐색이 필수적이게 됩니다. 따라서 (관계형 데이터 베이스를 사용한다면) 데이터베이스를 잘 설계하거나 엔티티 그래프 탐색을 어디까지 허용할지 제한을 잘 둬야 하는데, 이런 부분에서 팀원들과 협의가 맞아야 할 것 같습니다. 

 

 

또한 이 과정에서 추가쿼리가 1~2번 정도 더 발생할 수 있는데 이는 어느정도 감수해야할 영역이라고 생각됩니다. 

 

 

 

** 추가

엔티티에 로직이 많이 들어가는 것은 사실 장점이라 볼수 있는데요, 엔티티에 로직이 많이들어가게 되면 응집성이 증가하기 때문입니다. 하나의 엔티티에서 연관된 로직을 모두 처리하기 때문에 이를 통해 변경점을 줄일 수 있고 개발자가 실수할 여지가 줄어들게 됩니다.