개인적으로 고민하고 있는 것들 정리

지금껏 공부 & 개발을 해오며  고민하고 있는 것들이 많이 있다.

간간히 한번씩 쫙 나열을 해놓으면 공부 방향성을 재고해볼 수도 있고 나중에 봐도 재밌을 것 같다는 생각이 들어 짤막히 정리해본다.

 

고민

객체지향 & 도메인 주도적인 설계

여러 도메인을 아우르는 구현부의 패키지 위치

프로젝트의 유스케이스들을 코드로 옮겨내다보면, 여러 도메인을 가져와서 활용해야하는 상황이 많다.

(예시: 게시글을 삭제하기 위해선, 해당 게시글의 정보 (게시글 도메인)와 요청자 (유저 도메인)의 정보를 확인해야 한다)

 

그렇다면 이런 로직을 담아낸 클래스는 이름을 어떻게 짓고, 어느 패키지에 위치해야 할까?

 

'게시글 삭제'의 유스케이스니 ArticleService에 위치해야 하는걸까. 그런 식으로 구현하다보면 결국 이 Service에 어마어마한 엔티티들의 Repository 의존성이 쌓이게 되어버린다..

 

그건 어쩔 수 없는 숙명이라 하자. 그리고 우린 이런 복잡한 내부 구조를 뒤에 두고 사용자에게 간단한 인터페이스만 제공하는 디자인 패턴을 알고 있으니, 퍼사드 패턴이다.

 

내가 지금껏 얘기했던 레이어는 보통 많은 사람들이 Facade Layer라고 부르는 것 같다.

 

JPA

쿼리에서 로직 빼기

JPA를 사용하고 있지만, 여전히 쿼리는 JPQL이라는 이름으로 엄청나게 사용하고 있다.

 

https://youtu.be/fnH_SR3n9Ew

 

예전에 MyBatis로 짜여진 '모든 로직 프로시저 몰빵' 프로젝트를 만지던 시절, 이 영상을 보고 큰 충격을 받았던 적이 있었다.

쿼리에서 로직 빼기. 정말 정말 감탄을 많이 했고 지금도 웬만해선 지키려고 하는 룰이다.

 

하지만.. 요새 프로젝트를 하며 이게 참 어렵다고 느낀다.

 

조회 로직에서는 아무리 그러지 않으려고 해도 쿼리로 로직이 가게 된다.

(예시: 유저가 좋아요한 게시글을 모아보는 기능. 그런데 A가 쓴 글을 B가 좋아요했지만 그 글이 비공개가 된다면, B가 본인의 좋아요 목록을 볼 때는 A의 글이 보이지 않아야하지만, A가 볼 때는 본인의 글이 보여야한다)

 

이런 api를 구현하려면, 쿼리에 로직이 들어가게 된다.

물론 시원하게 findAll해가지고 서버 코드에서 직접 필터링해줄 수도 있지만.. 그런 것도 결국 한계가 있다고 생각한다.

 

조회 로직에선 정말 쿼리에서 이런 로직을 뺄 수 없는 것일까.

 

엔티티 간 연관관계 설정

JPA는 엔티티 간에 연관관계를 설정할 수 있다.

OneToMany, ManyToOne 등을 활용해서 단방향, 양방향으로 연관관계를 붙이면 정말 편리한 코딩을 할 수 있다.

 

하지만 이 연관관계를 어떻게 설정해야하는지 도저히 모르겠다.

 

옛날엔 무조건 엔티티들을 싸그리 양방향으로 설정했던 적이 있었는데, 나중에서야 김영한 선생님께서 '가능한 단방향'을 사용하라고 하신 것을 알게 됐다. 그리고 또 일대다 단방향도 좋지 않다고 하셨다..

 

그렇다면 남은건 다대일 단방향이구나! 그 이후로는 거의 다대일 단방향만 쓰고 다녔다.

그런데 또 어디선가 엔티티 연관보단, 그냥 long으로 PK만 들고 있는게 낫다는 얘기도 듣고.. (애그리거트 루트는 id로 참조를 갖는다?)

 

또 위에서 영상으로 소개드린 최범균님께선 연관관계를 아예 쓰지 않으신다고까지 한다. (대신 CQRS를 활용해서 조회 모델에선 JPA 대신 다른 무언가로 조회를 하신다고..)

 

아무튼 이 연관관계라는걸 대체 다른 사람들은 어떻게 가져가고 있는지. 다른 사람들은 도메인 객체를 어떻게 설계하는지.

또, N+1을 해결하기 위해, 어떤 식으로 쿼리를 구성하는지.

 

모든게 궁금하다.

 

 

배우고 싶은 것

멀티 모듈

이전에 제미니님의 '지속 성장 가능한 소프트웨어를 만들어가는 방법' 게시글과 영상을 본적이 있다.

https://geminikims.medium.com/%EC%A7%80%EC%86%8D-%EC%84%B1%EC%9E%A5-%EA%B0%80%EB%8A%A5%ED%95%9C-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EB%A5%BC-%EB%A7%8C%EB%93%A4%EC%96%B4%EA%B0%80%EB%8A%94-%EB%B0%A9%EB%B2%95-97844c5dab63

지속 성장 가능한 소프트웨어를 만들어가는 방법

 

굉장히 큰 충격을 받았고, 여기서 많은 분량이 들어있는 멀티 모듈에 대해서도 알게 되었다.

되게 신선한 느낌이었고  (멀티모듈이란 기술 자체는 오래됐지만) 격리라는 컨셉에 대해 공감을 많이 했다. 또한 써보면 프로젝트를 구조화하는 데에도 좋겠다는 생각이 들었다.

 

 

그런데 또 최근에 이 이규원님의 게시물을 보게 되었다.

개인적으로 이런 스타일의 게시물을 좋아하지 않는다. 문제 제기를 하고, 그래서 어쩌면 좋을지 해답을 안 알려주고 한 소리만 하고 끝내서 공익적인 취지가 정말 반만 있기 때문인데.

 

암튼 이 게시물을 보고 "흠.. 멀티모듈(의 폐해)가 그정돈가?" 싶어서 괜히 멀티모듈을 공부해야겠다고 생각하는거 자체가 소위 힙한거만 추종하는 힙스터충이 되는 것 같아서 괜히 기분만 나빠지는 느낌.

 

암튼 멀티 모듈 공부해보고 싶다.

 

QueryDSL

JPA로 조회 코드 짜는거 너무 고되다.

이 쿼리 DSL이라는걸 쓰면 되게 쿼리 짜는게 편해진다고 들었다.

 

공부.. 해보고 싶은데, 설정이 되게 복잡한게 싫어서 손을 못 대고 있다.

 

Kotlin

하도 좋다길래..

근데 또 슬쩍 슬쩍 보면 자바랑 코드가 꽤 다르다.

 

일단 지금의 내 단점은 코틀린을 배운다고 낫는건 아니기 때문에 후순위로 미룬다.

 

 

스프링 이벤트

되게 좋은 기술 같아서, 이번 프로젝트에 조금 써봤다.

좀 마음에 든다.

 

여러가지로 적극적으로 써볼 수 있으면 좋겠다.