Closed hyuk0309 closed 2 years ago
222 tests 222 :heavy_check_mark: 33s :stopwatch: 72 suites 0 :zzz: 72 files 0 :x:
Results for commit b1cb6c5d.
arch unit 을 한번 더 빡세게 커스터 마이징해서 저희가 의도하는 dependency rule 이 잘 지켜지고 있는지 자동화 검증 할 수 있으면 좋겠네요
어떤 느낌인지 알겠습니다 그럼 @Query를 제거하고 그냥 @Repository 컴포넌트로 가져가는게 덜 헷갈린거 같네요
@Query
FindProfileByIdQuery
->
@Repository
FindProfileByIdRepository
이렇게요
저희 논의/학습이 필요한 부분이 있어보입니다.
CQRS 가 api 레벨에서 발생하는 가장 큰 command/query 만 분리하는 건가요?? 혹은 발생가능한 모든 시나리오의 쿼리 (command 를 위한 query, 현재의 @Query와 같은 경우 등등)에 대해서 분리하는 건가요??
저는 후자로 생각했는데 크러쉬는 전자로 생각하는거 같네요 저는 그래서 command 패키지에서 query 패키지로의 참조 (command 모듈 에서 query 모듈을 호출)는 가능하며 자연스럽다고 생각했습니다.
구조 잡는게 정말 어렵네요…
계속 생각해봤는데 이런 느낌은 어떨까요?
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 |
어렵네용..
저희 논의/학습이 필요한 부분이 있어보입니다.
CQRS 가 api 레벨에서 발생하는 가장 큰 command/query 만 분리하는 건가요?? 혹은 발생가능한 모든 시나리오의 쿼리� (command 를 위한 query, 현재의 @query와 같은 경우 등등)에 대해서 분리하는 건가요??
저는 후자로 생각했는데 크러쉬는 전자로 생각하는거 같네요 저는 그래서 command 패키지에서 query 패키지로의 참조 (command 모듈 에서 query 모듈을 호출)는 가능하며 자연스럽다고 �생각했습니다.
저는 처음에 전자로 생각했어요. 그런데 코드를 계속 보니까 전자정도로 분리할 필요성은 없는 것 같아요. 오히려 복잡도가 올라가는 느낌이 드네요.. ㅎㅎ 그래서 후자로 가는게 괜찮을 것 같아요. 패키지 구조는 아직 고민중이에요! 😄
후자로 가면 제 생각에는 패지지 구조는
|-profile
| |- entity
| |- command
| |- service
| |- persistence
| |- query
| |- serivce
| |- persistence
가 괜찮을 것 같아요.
그리고 영속성 계층에서 Dao라는 용어의 사용보다는 QueryRepository를 사용하는건 어떤가요?
Dao는 도메인보다 DB와 가까운 용어고, Repository는 도메인에 가까운 용어라고 알고있어요. 그리고 저희는 결국 Profile 이라는 엔티티(도메인 모델)을 반환 받기 때문에 DAO보다는 Repository 용어가 더 어울리는 것 같아요.
좋습니다. 저도 그렇게 생각해요
위에 작성한 전자 후자 시리즈에서 후자가 분리정도, 복잡도 가 더 높지않나요?
구조 잡는게 정말 어렵네요…
계속 생각해봤는데 이런 느낌은 어떨까요?
domain.profile.
@Application layer, persistence layercommand 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
요거 말씀하는 건가요?
🛠️ 작업 내용
🗨️ 기타
repository
보다dao
개념에 가까워 네이밍을 변경했습니다. (참조)😎 리뷰어
@ndy2 , @jk05018 , @NewEgoDoc, @hyuk0309