私のドメインには、市の電気ネットワークを表すエンティティがあります。実際、私のモデルは、ブレーカー、変圧器、ラインを含むリストを持つエンティティです。
ブレーカーの開閉ごとにネットワークが変わり、ユーザーが接続を変更できるなど...
CQRS のすべての例で、EventStore は Version と aggregateId でクエリされます。
「ネットワーク」集約またはすべての「接続可能」アイテムに対してのみイベントを実装する必要があると思いますか?
この場合、(日付に基づいて) 「実際の」ステータスを取得するためにすべてのイベントを再生する必要がある場合、10000 から 20000 近くのイベントを処理することができます。
イベントは 1 つのプロパティを変更しますか、それともオブジェクト (オブジェクトのすべてのプロパティを含む) を変更するイベントが必要ですか?
ルールには常に例外がありますが、ドメインで処理されるすべてのコマンドに対してイベントが必要だと思います。スナップショットを利用することで、非常に多くのイベントを処理するという問題を回避できます。
http://thinkbeforecoding.com/post/2010/02/25/Event-Sourcing-and-CQRS-Snapshots
現在、「接続可能なアイテム」は「ネットワーク」集合体の一部であり、それらを独自の集合体にする必要があるかどうかを尋ねていると思いますか? それは実際にはシステムと問題の性質に依存し、単純な CQRS の問題よりも DDD の問題です。ただし、変更の性質が通常、アイテムを互いに独立して操作することである場合は、おそらくルート自体を集約する必要があります。いずれにせよ、その質問に答えるためには、モデル化しているシステムについてもっと知る必要があります。
何千ものイベントを再生するという課題については、コマンドごとにすべてのイベントを再生する必要はありません。確かにスナップショットはオプションですが、最初にロードされた後に集約ルートオブジェクトをメモリにキャッシュして、各コマンドでイベントからソースを取得する必要がないようにすることをお勧めします (システムがクラッシュしない限り、スナップショットに頼ることができます)。ただし、ロードのペナルティは一度しか支払われないため、キャッシングでは必要ないかもしれませんが、より迅速な回復のために）。
このシステムを複数のホストまたはスレッドに分散している場合、考慮すべき他の問題がいくつかありますが、議論は別の質問またはフォーラムに任せるのが最善だと思います.
最後に、イベントはオブジェクトの状態の複数のプロパティを変更できると思いますか? はい、そのイベントが表すものに基づいてそれが理にかなっている場合。イベントの考え方は、全体として状態の変化を表すという単純なものですが、これらのイベントは、ビジネスにとって意味のある概念も表す必要があります。
それが役立つことを願っています。