[LO-187] 프로필 도메인 CQRS 패턴 도입 초벌

[hyuk0309]

🛠️ 작업 내용

• 프로필 도메인 CQRS 패턴 도입 초벌

🗨️ 기타

• 코드가 DDD로 바뀌면서 데이터를 바꾸는 작업인 command성 작업과 데이터를 조회하는 작업인 query성 작업을 나눌 필요성을 느꼈습니다.
• 일단 목표는 어플리케이션 단계에서 CQRS 패턴을 도입하는 것입니다.
• 아직 모델 분리는 못했고, 프로필 도메인에서 command성 작업과 query성 작업을 패키지 단위로 분리하고, 이에 따라 테스트도 분리했습니다.
• 클래스가 가지는 책임이 분산되는 느낌이라 개인적으로 좋은 것 같습니다. 추후에는 query성 작업은 엔티티 모델을 활용하는게 아니라, dto 모델을 따로 만들어 사용할 예정입니다.

😎 리뷰어

@ndy2 , @jk05018 , @NewEgoDoc, @hyuk0309

[github-actions[bot]]

Unit Test Results

217 tests   217 :heavy_check_mark:  39s :stopwatch:   71 suites      0 :zzz:   71 files        0 :x:

Results for commit 06a38995.

:recycle: This comment has been updated with latest results.

[ndy2]

변경 중 이부분이 잘 이해 되지 않네요 프로필 커맨드 서비스에서 사용해서 커맨드로 분리된 것일까요?

또한 @Query 도 있고 @Service 도 있고 @Repository 도 있는데 XXXQueryService 는 네이밍 만 보았을때 @Query, @Service 가 모두 해당 될것 같고 XXXQueryRepository 는 @Query, @Repository 가 다 있어야 할 것 같다는 생각이 들어요

저는 개인적으로 현재 영속성 계층의 @Query 어노테이션을 서비스 어노테이션으로 변경하여 XXXQuery 시리즈를 서비스에서 사용하면 어떨까 싶네요

ps. 영한님의 사용자 정의 리포지토리 강의를 인상깊게 들으신것 같네요 👍 ps2. 계속 생각해봤는데 네이밍이 참 어렵네요 ps3. 또 생각해봤는데 계층형 아키텍처랑 cqrs 패키지 구조를 이쁘게 가져가기 어려운것 같네요 작성하신 패키지 구조는 어느 링크같은걸 참고 하신건가요?? 아예 검증된 hexagonal 아키텍쳐였으면 이런 고민이 없었을것 같네요

[ndy2]

• 일단 목표는 어플리케이션 단계에서 CQRS 패턴을 도입하는 것입니다. 최종 목표가 궁금합니다!

[hyuk0309]

프로필 커맨드 서비스에서 사용해서 커맨드로 분리된 것일까요?

넵! 커맨드성 작업에서 주로 사용하기 때문에 일단 command로 분류했어요. CQRS 패턴을 표현하기 위해선 command, query로 나누는게 명확하다 생각돼 네이밍을 지었는데, 역시나 기존 @Query 컴포넌트와 충돌이 생기더라고요. 이 부분은 command, query의 구분을 좀 더 명확히 하면서 계속 고민해야 할 것 같아요.

[hyuk0309]

또 생각해봤는데 계층형 아키텍처랑� cqrs 패키지 구조를 이쁘게 가져가기 어려운것 같네요 작성하신 패키지 구조는 어느 링크같은걸 참고 하신건가요?? 아예 검증된 hexagonal 아키텍쳐였으면 이런 고민이 없었을것 같네요

명확하게 참고할 코드를 찾아봤는데, 못 찾아서 최범균님의 블로그 그림을 참고해 설계했습니다. 참고

지금은 도메인 모델을 공유하고 있어 그림처럼 완벽하게 분리하지 못했어요~ 쿼리쪽을 dto 모델을 사용하는 방향으로 바꾸면 profile 하위에 command , query 패키지로 나눠 볼 생각이예요~

[hyuk0309]

현재 목표는 어플리케이션 단에서 cqrs 패턴을 도입하는거예요. 그리고 가능하다면 DB도 분리해 관리하면 재밌을 것 같아요~

[ndy2]

오 query 쪽은 api 에서 바로 repository 를 사용하나보네요 조회용 dto 를 사용하고 QueryRepository 말고 Dao 라는 이름도 좋네요