[고민] 유저가 작성한 게시글 조회는 누구의 관심사인가

이번 프로젝트의 백엔드 팀장을 맡다 보니, 나와 같이 커뮤니티 도메인을 개발하는 사람으로부터 엔티티 모델링을 앞두고 슬랙으로 다음과 같은 문의가 들어왔다.

 

그 다음은 개발 관련인데, 양방향 연결 관련해서 여쭤보고 싶은게 있습니다.
사실 항상 돌아가면 그만이지~ 하는 마인드로 개발을 해왔던지라 이렇게 고민하면서 개발하는게 어렵기도 하고 공부가 되는것 같아 좋네요…
제가 항상 개발을 해올 때 이렇게 User, Post가 있는 경우, User가 작성한 Post를 받아와야하는 경우도 있고, Post에서 작성한 User를 받아와야 하는 경우가 있다면 양방향으로 그냥 설정해두고 각 User,Post에서 빼내왔습니다.

그런데 보통 양방향 연관관계는 피할 수 있으면 피하라는 말을 들었었는데 마침 작성해주신 erd에도 User 엔티티에는 외래키가 없어서 이런 경우에 어떻게 처리하는 것이 best practice인지 의견을 여쭙고 싶습니다.
현재 erd 기준으로는 User테이블에 Post의 외래키가 존재하지 않아서 User가 작성한 Post를 검색하고 싶으면 PostRepository에서 User의 외래키로 조인을 해서 Post를 검색해야한다고 생각이 됩니다.
그런데 제가 이렇게 해본 적이 없어서 이런 방식이 객체지향적 설계를 지향하는 jpa에서 올바른 설계인지, 원래도 이런 식으로 설계를 하는지 궁금합니다. 인터넷에 검색을 해봐도 양방향 설계를 최대한 피하란 이야기만 있고 어떻게 해결을 해야하는지에 대한 방법은 나오지 않더라고요.

평소 대충대충~ 개발을 해오다보니 이렇게 고민이 발생하네요…

 

나는 이에 이렇게 답하였다.

 

제가 정답이라고 보장할 순 없다고 생각해서, 고민을 같이 해본다는 느낌으로 서술하겠습니다! 이건 사실 개발하는 사람이 고민하기 나름인 것 같은데, "객체지향적인 설계"라는 것을 논할 때 SOLID를 빼놓을 수 없잖아요? 뭔가 고리타분해 보이는 이름이지만, 어찌보면 객체지향이라는 개념을 정립할 때 기준이 되는 것이 SOLID다 보니 설계를 고민할 때 한번씩 다시 보는 것 같습니다.

여기서 S가 Single Responsibility Principle, 단일 책임 원칙이다보니 저는 "각각의 책임을 엄격히 분리한다면 해당 기능은 어디서 구현하는게 맞을까?"에 대한 고민을 먼저 할 것 같습니다. 지금 고민하시는 부분이 User가 작성한 Post는 UserService의 영역인가 PostService의 영역인가를 고민하시는 것 같다고 저는 느끼는데, 
저라면 PostService에서 제공할 것 같습니다. 말씀대로 객체지향적인 설계를 위해 JPA를 이용하여 자바의 객체와 테이블을 매핑하였고, 객체지향적인 설계를 고려하여 단일책임원칙을 지킬건데, "모든 포스트 조회" 이든 "특정 포스트 조회"이든, "특정 유저의 포스트 조회"이든 포스트가 가져야 하는 역할이니 Post 객체와 관련된 메서드라고 이해가 될 수 있을 것 같습니다. 그게 지금 우리가 해당 기능을 개발해야 하는 이유이기도 하구요. (UserService의 영역이라면 유저 도메인 담당 작업자님이 개발하는게 맞겠죠..?)

PostService의 영역이라면 고민할 것 없이 단방향인게 전혀 문제되지 않는 것 같습니다. 근데 저도 정답이 무엇인지는 잘 모르겠고, 그냥 우리가 충분히 고민한 뒤에 내린 결론들의 끝이 우리가 선택할 수 있는 그리디한 최선이라고 생각하면 될 것 같아요. 

 

개발을 할 때, 물 흐르듯이 좋은 코드를 작성할 수 있다면 얼마나 좋을까? 하지만 인간이기에 "더 좋은 구조"에 대한 고민을 항상 하면서 개발을 해야 하는 것 같다. 어떠한 작업을 수행하는 로직을 구성할 때에도, 양방향으로 모두 뚫어둔 구조에서는 유저 엔티티의 컬렉션 필드로부터 해당 유저가 작성한 게시글을 조회할수도 있었을 것이다.

 

사실 정답은 없고 구현하기 나름이라고 생각하기도 하거니와, 내가 현재 가지고 있는 이 생각도 나중에 더 성장한 내가 보면 논리가 부실한 결론이었을지 모른다는 생각이다.

 

그럼에도 불구하고, 이번 질문을 통해 다시금 느끼는 것은 "끊임없이 고민하면서 개발하자"이다. 안그래도 읽기 어려운 코드를 고민없이 대충 짜다가 매우 꼬여버리면 나중에 유지보수 할 때에 상당한 피곤함을 느끼게 될 것이므로... 합리적으로 짤 수 있게 노력하자.