CQRS 패턴 적용 및 provider의 역할 재정의

[hye-on]

도메인주도 설계 스터디를 같이 진행할 때 다음과 같은 내용을 공부했고,
어제 회의에서 얘기한 내용을 정리하고자 합니다.

cqrs패턴을 적용하는 것에 대해 어떻게 생각 하시는지 궁금합니다.
(어제 회의 이후로 다른 의견이 생겼으면 알려주세요!)

cqrs패턴을 도입한다면 provider가 query의 역할을 맡게 되는 것으로 정할까요?
(그러면 MissionProvider의 함수들이 재배치되어야할 것 같습니다!)

[05AM]

좋습니다. 사실 CQRS는 서비스를 분리하는 것보다는 모델을 분리하는 것에 핵심이 있다고 생각하고, 서비스를 명령과 조회에 따라 나눔으로써 두 서비스를 어떻게 차별화하여 구현할건지가 중요하다고 생각합니다.

그러한 설계가 없는 상황에서 서비스만 나누는 것은 책임 분리 그 이상의 의미는 없다고 생각하지만 후에 확장성을 생각하셔서 도입하자는 의견이라고 생각하고 도입에 찬성합니다.

찾아보니 추가적으로 transactional 설정을 다르게 하거나 캐싱 등의 작업을 처리하는 방법도 있다고 합니다! 후에 도입해볼 만한 기능인 것 같습니다.

[hye-on]

사실 CQRS는 서비스를 분리하는 것보다는 모델을 분리하는 것에 핵심이 있다고 생각하고, 서비스를 명령과 조회에 따라 나눔으로써 두 서비스를 어떻게 차별화하여 구현할건지가 중요하다고 생각합니다.

cqrs 패턴이 명령과 조희 모델을 구분하는 것이기 때문에, 도입을 하자는 의견을 당연히 명령과 조회 모델을 구분하는 것으로 이해하신 줄 알았습니다.
단순히 서비스만 분리하자는 것이 아니라 명령과 조회모델을 구분하자는 의견으로 생각해주시면 좋을 것 같습니다.

이렇게 생각했을 때 도입에 찬성하시는지 궁금합니다!
(조회 모델이 복잡한 것만(room) 분리를 하면 좋을 것 같습니다.)

[hye-on]

cqrs패턴을 도입할 때
query에 어떤 기술을 이용할지
어떤 도메인에 query를 적용할지 (room은 조회모델이 복잡하지만 미션은 복잡하지 않기 때문에)
를 논의 해야할 것 같습니다.

그리고 저번에 주신 의견 중에 room에 미션이미지를 추가하자는 의견은
조회 모델에 변경에 따라 도메인이 영향을 받는 것이기 때문에 지양해야 한다고 생각하고, cqrs패턴을 도입함으로써 해결할 수 있을 것 같습니다!

추가적으로 query에 어떤 기술을 사용할지에 대해 고민하고 있습니다.
query dsl 은 실무에서 많이 사용한다고 하지만 강의가 따로 있을 만큼 배우는데 드는 시간이 좀 들고 복잡한 쿼리를 해겨하는데 유용합니다.
그래서 JPQL을 이용한 동적 인스턴스 생성, 하이버네이트의 @subselect, 마이바티스중 고민입니다.

[hye-on]

• provider라는 이름이 모호한것 같아서
  RoomQueryService, RoomQuery 등으로바꾸는 것은 어떨까요?