post패키지 리팩토링하기
post패키지 리팩토링하기
초기 멤버인 재형씨가 개인사로 쿠스토랑을 관두게 되었다. 따라서 나는 작업이 필요하던 post패키지를 작업해보기로 했다.
우선 현재까지 최종 정리된 패키지는 다음과 같다.
comment는 댓글, post는 게시글, community는 조회의 역할을 담당한다.
1. 웹/앱 에서 개별 분리된 service layer를 하나로 통일했다. (ex. postApiService 와 postService를 하나의 postService로 통일)
2. 하나의 컨트롤러가 너무 비대했다. 대략 다음과 같이 나눠졌다.
- post - 게시글 에 대한 명령형 로직들 수행
- 게시글 생성,수정,삭제,이미지 업로드
- 게시글 좋아요,싫어요,스크랩
- community - 주로 조회를 담당하거나 조회에 필요한 로직들( ex. 게시글 상세 페이지 뷰 반환을 위해 댓글 트리 조합)
- 게시글 목록 조회, 검색 조회
- 게시글 상세 페이지 조회
- comment - 댓글 에 대한 명령형 로직들 수행
- 댓글 생성,삭제
- 댓글 좋아요,싫어요
필요한 request, response의 record 클래스들을 생성하고 이를 사용해 요청받고 응답해준다.
유저 랭킹 기능도 post내에 있었다 -> user 패키지의 ranking 패키지를 새로 만들어 여기로 이동했다.
(user 의 ranking 기능 관련 db로직은 native쿼리를 사용했다. 윈도우 함수와 CTE를 사용했기 때문인데 이는 jpql에선 지원하지 않기 때문이다)
3. 댓글 삭제 전략을 추가했다.
우리는 최대 2depth 댓글을 사용한다. 댓글에 대댓글이 달려있는 경우, 본 댓글은 '삭제되었습니다' 표시, 대댓글이 모두 삭제되는경우 전체 제거. 그 외에는 바로 제거
4. queryDSL 사용에 있어서 기존에는 하나의 거대한 dto projection을 공통으로 이용한 뒤, 필요한 정보들만 꺼내 사용했었다.
하지만 예를 들어 게시글 목록 조회에 필요한 정보는 게시글 하나의 상세 조회에 필요한 정보량에 비해 훨씬 적다. 따라서 정말 필요한것만 dto projection 하도록 수정했다. 또한 여러 필드들을 동시에 다수 join하고 distinct 한 후, groupBy 해서 사용하는 쿼리문이 있었는데 이는 초기 도입에 있어 chat gpt에 의존하다보니 발생한 문제로 추측된다. 수정하면서 가능한 join을 최소화하고 필요한 값들은 상관 서브쿼리로 뽑는 전략을 채택했는데, like/dislike를 두개의개별 테이블에서 하나의 테이블로 바꿨고, 집계 데이터가 필요한 경우엔 Expression등을 사용해서 표현식을 남기게 하였다.
5. 몇몇 스키마의 고유pk사용 대신 복합pk 사용하기.
게시글의 좋아요,싫어요 (유저반응) 테이블이나 스크랩여부 등의 테이블에도 auto increment로 할당된 고유 pk가 있었다. 하지만 만약 유저입장에서 좋아요를 눌렀다취소했다를 반복한다거나 스크랩 등록,취소를 반복한다면 의미없는 pk는 지속적으로 올라가게된다. 무엇보다 우리 서비스 정책에서 별도로 pk가 요구되지 않는다고 판단이 섰고, 따라서 고유한 값들을 복합 pk로써 사용하게 하였다.
또한 이번에 작업을 하면서 느낀 두가지에 대해 이야기해보면 좋을것 같다.
첫번째는 fk 설정이다. 역시 이번 작업에서도 DB 스키마 관련 변경을 꽤 하게 되었고, 이전부터 느꼈던 점과 더불어 과거에 읽었던 글들이 결합되어 머리속에 떠올랐다. 현업에서는 fk를 잘 사용하지 않는다는것, 실제로 빈번하게 db 스키마를 변경하면서 fk 제약조건은 꾀나 나에게도 번거롭게 다가왔다.
물론 인터넷에서는 훨씬 폭넓은 사유들이 존재한다. insert, update시에 참조된 테이블 행의 존재성을 검사하면서 발생하는 추가적인 오버헤드 라던가 갭락/넥스트 키 락 등으로 인한 데드락 빈도 발생 증가 위험이라던가 등등.. 많이 있었는데 이것 보다도 당장의 나 같은 경우엔 fk가 걸려있는 행의 번경이 지나치게 번거로웠다는 점이다. 확정적으로 안정적인 스키마에 fk를 적용하고, 개발 단계에서는 fk를 지양한다는 이야기가 조금은 와닫게 되었던것 같다. db 레벨에서 무결성을 보장해준다는 장점이 있지만 이를 뛰어넘는 단점이 아닌가 하고 생각하게 됬다.
두번째는 현재 post도메인 성격상 service layer를 굳이 인터페이스로 경계를 분리할 필요가 있느냐는 점이다. 정석적인 TDD에 따른다면 테스트코드 작성을 위해 인터페이스를 우선 만들었어야 했을 것이다. 나는 지금 post도메인 성격상 서비스 레이어의 인터페이스 분리가 완전히 필요없게 느껴진다. 오히려 더 번거롭다고 느껴진다. DDD던 hexagonal이던 경계분리에는 분명 적절한 목적성이나 근거가 있었다. 하지만 여기서는 필요가 없는것 같다. 그래서 여기서는 분리를 안하고자 한다.