[LO-205] 프로필 도메인 cqrs 구조 잡기

[hyuk0309]

🛠️ 작업 내용

• 프로필 도메인 cqrs 구조 잡기

🗨️ 기타

• profile 도메인에서 쿼리용 코드와 커맨드용 코드를 나눴습니다. 저번에 말씀드린데로 크게 entity, query, command로 나눴습니다. (#192 )
• 그러면서 자연스럽게 FindProfileByIdQuery가 분해됐고, 이놈의 역할을 profileQueryService가 맡게 됐습니다. (도메인 서비스 같다는 느낌이 드네여)

😎 리뷰어

@ndy2 , @jk05018 , @NewEgoDoc, @hyuk0309

[github-actions[bot]]

Unit Test Results

225 tests   225 :heavy_check_mark:  33s :stopwatch:   70 suites      0 :zzz:   70 files        0 :x:

Results for commit de8fd523.

[ndy2]

저희 둘다 범균님 cqrs 영상이나 책에 자주나오는 커맨드 모델과 쿼리 모델에 대한 개념을 확실히 하는게 필요할것 같아요.

제 생각에는 Query 쪽에서는 아예 @Entity 에 해당되는 command.entity.Profile 을 접근 하면 안될거 같아요

[ndy2]

entity, query, command 로 나누고 모델을 query 와 command 에서 공유하면 cqrs 를 했다고 보기 힘들것 같아요. (혹시 변경 중이시거나 변경 할꺼라고 말씀 하셨었으면 죄송합니다 ㅠ.ㅠ)

아니라면 범균님 cqrs 영상 다시한번 정독 해보시죠

[hyuk0309]

하하 말에 적극 동의합니다.

근데 현재 상황에서 모델을 분리하기 위해서는 조회 작업에서 프로젝션을 사용하는 방식으로 바꿔야 됩니다. 그런데 저희는 엔티티들을 가져와 조립하는 방식으로 조회 작업을 풀었습니다. 그래서 프로젝션을 사용하는 방법을 바로 도입하는데 어려움이 있었습니다. 그 외에도 프로젝션보다 우선순위가 높은 작업 (정책 관련, 어그리게이트 분리, 테스트 리팩토링)이 남아 있습니다.

그래서 일단 조회성 작업을 띄는 친구들과 명령성 작업을 하는 친구들로만 책임을 클래스 레밸에서 분리했습니다. 분리하면서 또 든 생각이 현재 저희 목록 조회 방식에서는 쿼리 서비스라는 도메인 서비스를 두고, 응용서비스에서 엔티티들을 말아주는 역할을 하는게 더 적절할 것 같습니다. 이도 한번에 바꾸진 못하겠죠... 😢

[ndy2]

아하 역시 그렇군요 막상 계속 학습을 진행중인데 조금 의아한 구조같아서 한번 말씀드렸습니다.

진짜 아키텍처라는게 정말 빡세네요 ㅋㅋ

[hyuk0309]

좋은 피드백 감사해요! 👍

좋은 설계 증말 어렵네요. 🥲 ㅎㅎ