-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
논의해볼 사항들 #142
Comments
자잘하게 논의할 사항이 있는 것 같아 기술적인 문제인 command와 query에 관한 의견을 각자 코멘트로 정리한 후에 회의하는 건 어떨까요? 다른 의견들도 원하시면 정리해서 적어도 좋습니다! |
command와 query를 분리cqrs패턴 자체가 command와 query를 분리하는 것인데 (낮은 수준에서는 폴더,더 높은 수준에서는 db, 사용 기술을 분리) (같이 스터디한 책의 레포에서도 command와 query를 폴더를 분리하며 설명하고 있습니다.) 작업 방식협업 방식에 대해 제안합니다. 그래서 제가 제안하고 싶은 방식은 각각 맡은 도메인의 리팩토링은 그대로 진행하고 , 앞으로 2주 (회의가 2주 간격이라서)단위로 해야 할 일을 같이 논의한 후 분담하면 어떨까요? ex) 2주동안 할 일
n일 이상 리뷰 댓글 미확인 시저희가 Dn룰을 최초 리뷰에만 적용하고 있다보니 그 후의 리뷰에 대해서 확인이 늦어지고 있습니다. 제가 생각한 방안
|
저희 프로젝트는 JPA 엔티티와 도메인 모델이 한 클래스에 구현되어 있기 때문에 CQRS 패턴 적용시 패키지를 분리하는 것에 동의합니다. 하지만 모든 도메인 패키지에서 패키지를 분리하는 것 보다는 읽기, 쓰기 모델을 최적화하는 도메인에서만 분리한다면 좋을 것 같습니다. 읽기, 쓰기 모델이 분리되지 않은 상황에서 패키지만 나누는 것은 복잡도를 가중시켜 큰 이점이 없을 것 같습니다. 패키지 분리에 대한 제 의견은 이렇고, 의논하고 싶은 부분은 cqrs 패턴 적용시에 서비스명을 어떻게 할지 정하면 좋을 것 같습니다! |
패키지 분리에 대한 의견이 같았네요 차이가 나는 부분이 "읽기, 쓰기 모델을 최적화하는 도메인" 의 기준인 것 같아요 아래 댓글로 남겨주신 "서비스의 기능을 구분한다는 의미" 로 쿼리서비스라고 하셨는데 어떤 기능을 구분하는지 궁금합니다.
000커멘드 서비스, 000쿼리 서비스로 해도 좋을 것 같습니다! |
cqrs 패턴에 대해 의견만 적고 회의에서 논의하려고 생각했는데, 글이 길어질 것 같아 코멘트로 먼저 정리해두겠습니다! 제 생각와 관련 글들을 종합하여 말씀드리자면 cqrs 패턴을 적용하는 이유는 쿼리와 커맨드 시에 다른 것을 사용하기 때문입니다. 예를 들어 jpa에서는 entity를 다르게 사용한다던지, query/command 패키지별로 db를 다르게 사용한다던지의 방법이 있을 것 같습니다. 그런데 쿼리와 커맨드의 실행에서 다른 점이 없는 도메인에 굳이 패키지를 나눌 필요는 없다고 생각합니다. 만일 저희가 단일 jpa 엔티티를 사용하고 있는 상황에서 query와 command로 패키지를 분리하고 각각 controller, service, domain을 정의한다면 해당 엔티티는 어디에 위치해야 할지 의문이 드는 것 같습니다. 그래서 저의 의견은 명확히 cqrs 패턴을 적용하여 query와 command 사이에 다르게 적용하고 있는 부분이 있는 도메인을 해당 구조로 패키지를 나눴으면 좋겠습니다! 그렇지 않은 상황에서 패키지만 나누는 것은 구조의 복잡도를 높이는 원인이 될 것 같습니다. |
☀️설명
☀️논의 사항
찬미
혜온
The text was updated successfully, but these errors were encountered: