[LO-189] 프로필 도메인 CQRS 패턴에 맞게 패키지 구조 변경 & 네이밍 변경

[hyuk0309]

🛠️ 작업 내용

• 프로필 도메인 CQRS 패턴에 맞게 패키지 구조 변경 & 네이밍 변경

🗨️ 기타

• 범균님의 블로그를 참조해서 패키지 구조를 나눴습니다.
• query 패키지에서는 repository 보다 dao 개념에 가까워 네이밍을 변경했습니다. (참조)
• 현재는 command, query 패키지가 완전히 분리되지 않았습니다. 예를 들면 query 패키지에서 아직 command 패키지의 도메인 모델을 사용합니다. 이도 추후에 완전히 분리할 생각입니다.
• 하하가 @Query 시리즈를 서비스로 바꾸고 query 패키지에서 사용하자고 제안해 주셨습니다. 그런데 생각해보니 CQRS 패턴을 사용하는 이유가 command, query 패키지를 분리해 명령성 작업과 조회성 작업을 분리해 관리하는 것이기 때문에 제안해 주신 방법은 힘들 것 같습니다. (쉽게 생각하면 command 패키지와 query 패키지는 독립된 모듈이라고 생각하시면 편할 것 같습니다.) 😄
• 카테고리 서비스를 다시 북마크로 옮겼습니다... 왜냐하면 카테고리 서비스가 하는일이 사용자가 작성한 북마크의 카테고리 목록을 가져오는 것이기 때문에, 선호 카테고리와는 개념적으로 다른 것 같습니다. 또 해당 작업을 수행하기 위해서는 북마크 엔티티에 접근해야 하기때문에 북마크 패키지 하위에 있는게 맞다고 생각됩니다.

😎 리뷰어

@ndy2 , @jk05018 , @NewEgoDoc, @hyuk0309

[github-actions[bot]]

Unit Test Results

222 tests   222 :heavy_check_mark:  33s :stopwatch:   72 suites      0 :zzz:   72 files        0 :x:

Results for commit b1cb6c5d.

[ndy2]

arch unit 을 한번 더 빡세게 커스터 마이징해서 저희가 의도하는 dependency rule 이 잘 지켜지고 있는지 자동화 검증 할 수 있으면 좋겠네요

어떤 느낌인지 알겠습니다 그럼 @Query를 제거하고 그냥 @Repository 컴포넌트로 가져가는게 덜 헷갈린거 같네요

@Query
FindProfileByIdQuery

->

@Repository
FindProfileByIdRepository

이렇게요

[ndy2]

저희 논의/학습이 필요한 부분이 있어보입니다.

CQRS 가 api 레벨에서 발생하는 가장 큰 command/query 만 분리하는 건가요?? 혹은 발생가능한 모든 시나리오의 쿼리 (command 를 위한 query, 현재의 @Query와 같은 경우 등등)에 대해서 분리하는 건가요??

저는 후자로 생각했는데 크러쉬는 전자로 생각하는거 같네요 저는 그래서 command 패키지에서 query 패키지로의 참조 (command 모듈 에서 query 모듈을 호출)는 가능하며 자연스럽다고 생각했습니다.

[ndy2]

구조 잡는게 정말 어렵네요…

계속 생각해봤는데 이런 느낌은 어떨까요?

domain.profile. @application layer, persistence layer

	command	query
web 계층 (controller)	web.profile.command.controller -> @Controller ProfileController	web.profile.query.controller -> @Controller ProfileQueryController
web 계층 (controller)	web.profile.command.request -> RegisterProfileRequest,UpdateProfileRequest	web.profile.query.response -> GetProfilesResponse, GetDetailedProfilesResponse
application 계층	command.application.command -> @Command ProfileCommand	query.application.query -> @Query ProfileQuery
application 계층	command.application.model -> RegisterProfileCommand,UpdateProfileCommand '하....'	query.application.model -> 없음 - 영속성 모델 재활용
persistence 계층	command.persistence.repository -> @Repository ProfileRepository @Repository FindProfileByIdRepository	query.persistence.dao -> @Dao ProfileDao @Dao FindProfileByIdDao
persistence 계층	command.persistence.model -> @Entity Profile,@Entity Follow,@Embeddable Reactions, ...	query.persistence.model -> ProfileFindCond, FindProfilesResult FindDetailedProfilesResult

[ndy2]

2안 컨트롤러는 현재 그대로, @Query 적용 위치에 따라 command, query 로 분해 후 패키지에 따라 FindXXXRepository, FindXXXDao 로 분해

	command	query
service 계층	command.service -> @Service ProfileService	query.service -> @Service ProfileQueryService
service 계층	command.service.model -> RegisterProfileCommand,UpdateProfileCommand 그대로	query.service.model -> 없음 - 영속성 모델 재활용
persistence 계층	command.persistence.repository -> @Repository ProfileRepository @Repository FindProfileByIdRepository	query.persistence.dao -> @Repository ProfileDao @Repository FindProfileByIdDao
persistence 계층	command.persistence.model -> @Entity Profile,@Entity Follow,@Embeddable Reactions, ...	query.persistence.model -> ProfileFindCond, FindProfilesResult FindDetailedProfilesResult

[ndy2]

어렵네용..

[hyuk0309]

저희 논의/학습이 필요한 부분이 있어보입니다.

CQRS 가 api 레벨에서 발생하는 가장 큰 command/query 만 분리하는 건가요?? 혹은 발생가능한 모든 시나리오의 쿼리� (command 를 위한 query, 현재의 @query와 같은 경우 등등)에 대해서 분리하는 건가요??

저는 후자로 생각했는데 크러쉬는 전자로 생각하는거 같네요 저는 그래서 command 패키지에서 query 패키지로의 참조 (command 모듈 에서 query 모듈을 호출)는 가능하며 자연스럽다고 �생각했습니다.

저는 처음에 전자로 생각했어요. 그런데 코드를 계속 보니까 전자정도로 분리할 필요성은 없는 것 같아요. 오히려 복잡도가 올라가는 느낌이 드네요.. ㅎㅎ 그래서 후자로 가는게 괜찮을 것 같아요. 패키지 구조는 아직 고민중이에요! 😄

[hyuk0309]

후자로 가면 제 생각에는 패지지 구조는

|-profile
|  |- entity
|  |- command
|        |- service
|        |- persistence
|  |- query
|        |- serivce
|        |- persistence 

가 괜찮을 것 같아요.

[hyuk0309]

그리고 영속성 계층에서 Dao라는 용어의 사용보다는 QueryRepository를 사용하는건 어떤가요?

Dao는 도메인보다 DB와 가까운 용어고, Repository는 도메인에 가까운 용어라고 알고있어요. 그리고 저희는 결국 Profile 이라는 엔티티(도메인 모델)을 반환 받기 때문에 DAO보다는 Repository 용어가 더 어울리는 것 같아요.

[ndy2]

좋습니다. 저도 그렇게 생각해요

[ndy2]

위에 작성한 전자 후자 시리즈에서 후자가 분리정도, 복잡도 가 더 높지않나요?

[hyuk0309]

구조 잡는게 정말 어렵네요…

계속 생각해봤는데 이런 느낌은 어떨까요?

domain.profile. @Application layer, persistence layer

command query web 계층 (controller) web.profile.command.controller -> @Controller ProfileController web.profile.query.controller -> @Controller ProfileQueryController web 계층 (controller) web.profile.command.request -> RegisterProfileRequest,UpdateProfileRequest web.profile.query.response -> GetProfilesResponse, GetDetailedProfilesResponse application 계층 command.application.command -> @Command ProfileCommand query.application.query -> @Query ProfileQuery application 계층 command.application.model -> RegisterProfileCommand,UpdateProfileCommand '하....' query.application.model -> 없음 - 영속성 모델 재활용 persistence 계층 command.persistence.repository -> @Repository ProfileRepository @Repository FindProfileByIdRepository query.persistence.dao -> @Dao ProfileDao @Dao FindProfileByIdDao persistence 계층 command.persistence.model -> @Entity Profile,@Entity Follow,@Embeddable Reactions, ... query.persistence.model -> ProfileFindCond, FindProfilesResult FindDetailedProfilesResult

2안 컨트롤러는 현재 그대로, @query 적용 위치에 따라 command, query 로 분해 후 패키지에 따라 FindXXXRepository, FindXXXDao 로 분해

command query service 계층 command.service -> @Service ProfileService query.service -> @Service ProfileQueryService service 계층 command.service.model -> RegisterProfileCommand,UpdateProfileCommand 그대로 query.service.model -> 없음 - 영속성 모델 재활용 persistence 계층 command.persistence.repository -> @Repository ProfileRepository @Repository FindProfileByIdRepository query.persistence.dao -> @Repository ProfileDao @Repository FindProfileByIdDao persistence 계층 command.persistence.model -> @Entity Profile,@Entity Follow,@Embeddable Reactions, ... query.persistence.model -> ProfileFindCond, FindProfilesResult FindDetailedProfilesResult

요거 말씀하는 건가요?