Repository 대신 Reader / Writer 사용 질문있습니다!!

안녕하세요. 답변이 늦어 죄송합니다.

요지는 JPA의 주요 기능 중 하나인 더티 체킹을 사용해도 되냐인 것 같습니다. 그런데 이 질문에 대한 답은 제가 섣불리 이렇게 해라 저렇게 해라 대답할 수 있는 부분은 아닌 것 같다는 생각이 드네요. ‘더티 체킹을 사용해선 안 된다!’라고 대답하면 JPA에서 제공하는 편리한 기능들을 사용하지 말라는 의미와 같으니까요. 그렇게 되면 JPA를 사용하는 이유가 없어질 겁니다.

그런데 아이러니하게 그게 또 강의에서 하고 싶은 말이기도 합니다. 꼭 JPA가 아니어도 되는 시스템을 만들 수 있어야 한다고 말하고 싶었습니다. 강의에서는 시스템은 언제든 MyBatis, JdbcTemplate 같은 것으로 다른 라이브러리로 교체될 수 있어야 한다고 말합니다. 나아가 Mongo 같은 데이터베이스로도 교체될 수 있어야 한다고 말합니다. 그런 관점이라면 JPA의 더티 체킹 기능에 의존하는 앱을 만드는 것은 바람직하지 않은 겁니다.

그래서 이에 대한 결정은 조직의 선택을 따르는 게 맞습니다. JPA의 편리한 기능을 이용해서 개발 속도를 빨리할 수도 있습니다. 프로젝트의 성격에 따라 다르다는 의미입니다. 게다가 솔직한 이야기로 현재 자바를 다루는 개발자치고 스프링과 JPA 이상가는 라이브러리를 찾는 것은 쉽지 않으니까요. 따라서 JPA 사용 자체를 부정하는 것은 아닙니다.

자바 세계에서 JPA가 메인 스트림이 된 지는 생각보다 얼마 되지 않았습니다. 그래서 업계에서는 JPA를 이전의 설계 이론에 맞게 잘 활용하는 방법에 대한 고민이 충분히 되지 않았다고 생각합니다. 질문자님의 고민은 그래서 더 가치 있고 고민이 많이 될 것 같습니다.

그리고 물론 JPA를 이용해 CQRS를 적용할 수도 있습니다. 저의 짧은 견해로는 아래와 같은 흐름으로 개발되면 되지 않을까 생각되네요. CQRS에 관한 공부는 저도 아직 진행 중이고 고민 중인 터라 참고만 해주시길 바랍니다.

Service의 로직
방법 a. 
1. Reader에서 UserReadonly를 불러옴
2. UserUpdateCommand 모델을 만들어 Writer에 요청

방법 b.
1. 필요에 따라 Reader에서 UserEditable을 불러옴 
2. 변경된 UserEditable을 Writer에 저장 요청 

답변 미제공 강의 유형으로 선택한 이유는 퇴근 후에 항상 사이드 프로젝트를 하고 있어서 그렇습니다. 질의 응답을 계속 책임지고 볼 자신이 없어서요. 글 쓰는 속도도 좀 느리고요. ㅎ;; 그래도 궁금해하시는 분들도 많고 저 또한 좋은 개발 방법론에 대해 토의하는 것을 좋아하기 때문에, 기회가 될 때 최대한 몰아서 답변할 수 있도록 해보겠습니다. CQRS과 관련해서 좋은 인사이트를 얻으셨다면 저도 좀 알려주세요. :)

안녕하세요, 인프런 AI 인턴입니다.

Reader와 Writer를 사용하여 개발 중이시군요.

JPA에서 더티 체킹을 사용하고 계시다면, Writer 내에서 엔티티를 조회해도 상관 없습니다. 하지만, 효율적인 코드를 작성하기 위해서는 Writer 내에서 불필요한 Entity의 조회는 하지 않는 것이 좋습니다.

따라서, Reader에서 엔티티를 조회하여 해당 엔티티를 Service로 반환한 다음, 그 엔티티를 Writer로 넘겨주시는 방법을 사용하셔도 무방합니다.

그리고, 해당 강의가 지식공유자 답변 미제공 강의이신데 선생님의 지식과 배려로 많은 도움이 된다면 다행입니다. 저희도 사용자분들께 최고의 서비스를 제공하기 위해 연구하고 노력하겠습니다.

감사합니다.