CQRS 1st NF 모델 읽기 - 극단적으로 복제를 허용합니까?

Question

첫 번째 실제 CQRS 설정부터 시작합니다. 나는 사이트의 사용자 등록 부분을 구축하고 있는데, 도메인과 쓰기면은 표준 DDD "스타일"에서 나오는 친숙한 부분입니다. 읽기 모델의 경우 AccountCreatedEvent를 처리하는 비정규 화기가 있습니다.

현재 구현중인 기능에 대해서만 사용자 등록에 관심이 있습니다. 이메일 주소/사용자 이름의 고유성 검사가 필요합니다.

그래서이 목적을 위해 특별히 읽기 모델을 디자인한다고 가정 해보십시오. 지금 관심이있는 데이터 부분 만 보유하고있는 AccountRegistrationReadModel : Username, Email, HashedPassword

나중에 사용자 프로필 페이지를 빌드하기 시작할 때 AccountProfileReadModel이 필요합니다.

이 읽기 ​​모델은 동일한 속성의 일부를 공유하고 AccountRegistrationReadModel과 AccountProfileReadModel가 듣기에 관심이 시점에서 아마도 예를 들어, AccountUsernameChangedEvent

을 변경 프로파일 데이터에 관련된 이벤트를 처리하는 또 다른 denormalizer이있을 것이다 AccountUsernameChangedEvent 메시지.

내 질문은 :이 접근법이 맞습니까? 기능마다 읽기 모델을 유지해야합니까? 또는 데이터를 표준화하고 데이터를 재사용하려고 할 때 가능한 경우 중복을 제한해야합니까?

Answer 1

나는 대부분의 디자인 질문과 마찬가지로 대답은 당신에게 달린 것이라고 생각합니다. 공유하면 컴퓨팅 리소스가 절약되고 시간이 지남에 따라 디버깅해야하는 작업 영역 수가 제한됩니다. 그러나 공유는 또한 잠재적으로 불필요하게 잠재적으로 다른 유형의 비용을 발생시키는 일을 결합합니다. 수천 명의 사용자와 지루한 쿼리가있는 시스템에서 데이터베이스의 단순하고 고전적인 사용자 테이블은 대부분의 읽기 모델에서 사용할 수 있습니다. 거대한 수의 사용자 또는 많은 수의 메시지로 확장해야하는 경우 다른 뷰 (감사 로그, 현재 활성 발송물 등) 중 일부가 더 재미있는 비정규 화 또는 구현과 관련 될 수 있습니다.

Answer 2

@Sebastian이 대답 한 내용에 동의합니다. 제 의견으로는 CQRS 패턴을 사용하면 정규화로 인해 약간 더 느린 수정 프로세스를 희생하여 빠르게 읽을 수있는 능력이 있다는 것입니다. 평범한 데이터를 읽지 마십시오. 결과적으로 데이터 저장소에 일부 중복이 생깁니다. 하지만 귀하의 비정규 기는 그 정보를 최신 상태로 유지합니다.

@Sebastian이 말했듯이, 그것은 당신에게 달려 있습니다. 그러나 CQRS로 옮길 때의 주요 이점은 빠른 읽기와 확장 성입니다. 데이터를 표준화하고 모델간에 데이터를 공유하기 시작하면보다 전통적인 CRUD 애플리케이션으로 돌아가고 있습니다. 이 시점에서 CQRS는 실제로 당신을 돕지 못하기 때문에 사용하는 것이별로 중요하지 않을 수 있습니다.

희망이 도움이됩니다. 행운을 빕니다!