5

접근 방식 이벤트 소싱/DDD/CQRS로 디자인 된 응용 프로그램에서 쿼리에 대한 게시물을보고있었습니다.DDD/CQRS 이벤트 쿼리

저는 이벤트가 도메인 개체의 상태가 변경된 것으로 알고 있습니다. 상태에 대한 변경 사항은 DB (모든 sql/no sql)의 내역/이벤트로 유지됩니다.

사용자가 특정 집계 루트에 대한 현재 상태를 얻기 위해 쿼리하려는 경우 이벤트 기록을 가져 오는 작업이 필요합니다.

사용자가 특히 비즈니스 관련 검색어를 쿼리 할 때 해당 사용자는 이벤트의 기록이 아닌 현재 상태에 관심을 갖습니다.

CQRS의 쿼리 또는 'Q'부분은 이벤트 소싱과 어떻게 작동합니까?

도메인 개체 "계정"을 집계 루트로 생각하십시오. 계정 AR은 많은 변경 (예 : 크레딧 청구)을 수행합니다. 이벤트 저장소에는 대변 및 차변 이벤트가 있습니다.

계정의 현재 잔액을 얻으려면 사용자가 필요하며, 이벤트 기록은 어떻게 저장 되나요? 사용자가 주어진 계정의 현재 잔액을 어떻게 가져 옵니까?

비즈니스에 대한 특정 검색어 기록은 어떻게 유용할까요?

-Prakhyat M M은

답변

4

당신은 쿼리 쪽 (Q)가 필요로하는 바로 그 정보가 들어있는 읽기 모델에 이벤트 스트림의 투영을 사용합니다. 예를 들어 계정 잔액을 변경하지만 계정 스트림의 다른 이벤트 (소유자 변경 등)를 무시할 수있는 모든 이벤트를 '계정 잔액'으로 예측할 수 있습니다. 그런 다음 투영은 정보를 매우 신속하게 쿼리 할 수있는 방식으로 저장합니다 (예 : 메모리 또는 작은 읽기 모델 데이터베이스 테이블 (accountId, balance)). accountId을 키로 사용합니다 (데이터베이스는 키 - 값 저장소가 될 수 있음) .

this one 또는 this one과 같은 CQRS 개념에 대한 추가 정보를 제안합니다.

+0

Alexander, 답장을 보내 주셔서 감사합니다. 나는 실종 된 문맥을 가지고있다. 예상은 실제로 효율적입니다. – Prakhyat

+0

Alexander, 내 앱에 akka persistence를 사용하고 있습니다. 나는 DDD/CQRS 접근법을 택했다. 나는 쓰기 측면에서 아무런 문제가 없다. 필자는 질의 측면을 구축하는 데 충분한 지식이 없다고 느낍니다. 쿼리가 여러 집계 루트의 데이터를 필요로 할 때 어떤 경우가됩니까? – Prakhyat

+0

죄송합니다. 나는 akka persistence에 대한 경험이 없습니다. 귀하의 투영은 물론 여러 집계 루트 (다른 ​​유형의 경우에도)를들을 수 있습니다. –

4

저는 Greg Young (그는 CQRS와 Event Sourcing의 아버지와 같습니다)에서 더 많은 기사를 읽으시기 바랍니다 : CQRS, Task Based UIs, Event Sourcing... agh.

내 나쁜 영어로 죄송합니다. 저는 파라과이 출신입니다. 하지만 저는 DDD - CQRS - ES를 정말 좋아합니다. 나는 한 가지를 지적하고자합니다.

"프로젝션"(Materialized Views라고도 함)의 사용과 "최종 일관성"의 개념은 CQRS의 모든 실무자가 잘 이해해야하는 기본 사항입니다. 이벤트 저장소는 쿼리 용입니다. CQRS의 명령 측면에 있고 쿼리 측면에는 없습니다. 버스를 사용하여 이벤트 저장소에 저장된 이벤트를 쿼리 측에 보내어 읽기 모델을 처리 및 생성하거나 쿼리 할 수있는 모델을 볼 수 있습니다. 어떤 경우 든 이벤트 저장소는 쿼리 모델입니다.

자바 사람처럼 보이지만, 여전히 CQRS Journey from Microsoft을 확인하고 싶을 수 있습니다. 조금만 있으면 도움이 되었기 때문에 비즈니스 애플리케이션 라인의 새로운 트리오 인 DDD/CQRS/ES에 대한 더 많은 연구를 할 수 있습니다.

2

흥미롭게도 최근에는 이벤트 저장소를 읽기 모델로 사용하여 더 많은 사람들이 프로젝션과 "적절한"읽기 모델을 절대적으로 필요로 할 때까지 발견했습니다.

투영을 처리하면 복잡성이 증가한다는 사실을 모두 알고 있습니다. 최소한 새 모델을 만들고, 읽은 모델에 대해 DAL을 설정하고, 읽은 모델 변경 사항으로 이벤트를 변환하고 예상치를 저장소의 이벤트 스트림에 바인딩해야합니다. 더 많은 코드와 더 많은 움직이는 부품이 필요하며 그 중 일부는 테스트하기 쉽지 않습니다. 읽기 측면에서의 스키마 변경에도 마이그레이션이 필요합니다.

많은 시나리오에서 모든 이벤트를 읽으면 (적절하게 파티션 된 경우) "읽기 모델"로 충분할 수 있습니다. 시스템이 실제로 커질 때까지는 시간이 많이 걸리지 않으므로 UI ​​화면 하나를 만들기 위해 수만 개의 이벤트를 읽어야합니다. 그러나이 시점에 도달하기 전에 이벤트를 읽을 수 있습니다. EventStore와 같은 도구는 무료이고 사용하기가 쉽지만 이벤트를 저장할 파일 시스템을 사용할 수도 있습니다. 색인을 추가 할 수 있습니다.

이 방법을 사용하면 도메인을 크게 안정화시키고 시스템 작동 방식에 대한 지식을 얻고 이벤트를 조정하고 "올바른"읽기 모델을 시스템에 가져올 준비가되어 있지만 그렇게 할 필요는 없습니다.

Adam Dymitruk이 blog post about it이라고 썼다면,이 접근법을 사용하고 싶지 않아도 읽을 가치가 있습니다. Greg Young도 2012 년에 EventStore as read model 번담을했습니다.