Event sourcingとCQRSを使用する際の短所は何ですか？

Question

イベントソーシング、それは開発者がビッグデータ移行プロジェクトがなければ、開発者はアプリケーションの存続期間で動作するように持っている1つの事前にモデル化データベースで立ち往生しているのRIDなるのでCQRSは素晴らしいです。 CQRSとESには、イベントストア、監査ログなどのスケーリングのような、インターネット上に既に存在する他の利点もあります。

しかし、どのような欠点がありますか？ここで

が、私は複雑な

1. 小さなデモアプリケーションを調査し、書き込み後に考えることができますいくつかの欠点です：一部の人々は、ESが複雑であると言います。しかし、私は複雑なアプリケーションを持つことは、クエリ言語（複数の結合、インデックスなど）を使用して非常に制限付きのクエリを実行できる複雑なデータベースモデルよりも優れていると言います。 Scalaのようなプログラミング言語の中には、非常に豊富なコレクションライブラリがあり、非常に複雑な集約を作成するのに非常に柔軟性があります。また、Apache Sparkがあります。しかし、データベースは常にクエリ言語の機能に制限され、データベースの配布は難しくなり、分散アプリケーションコード（別のマシンに別のインスタンスをデプロイするだけです）。
2. ディスクの空き容量が多い：イベントストアは、イベントを格納するために大量のディスクスペースを使用する可能性があります。しかし、数週間おきにクリーンアップをスケジュールし、スナップショットを作成することができます。将来、古いイベントが必要になったときに、履歴イベントをローカルHDに保存できますか？
3. ハイメモリ使用量：すべてのドメインオブジェクトの状態は、RAMの使用量が増加する可能性がありますメモリに格納され、RAMは、私たちすべてがどのように高価です。 大きな問題！私は貧しいですから！これに対する解決策はありますか？メモリに状態を格納する代わりにSqliteを使用することができますか？アプリケーションに複数のSqliteインスタンスを導入することで、より複雑なものになっていますか？
4. 起動時間が長くなる：イベントが発生すると、障害発生またはソフトウェアアップグレードの起動が遅くなります。しかし、我々はこれを解決するためにスナップショットを使うことができますか？いくつかのアプリケーションのための問題：
5. 結果整合。 FacebookがCQRSでイベントを保管してポストを保管し、忙しいフェイスブックのシステムがどのようなものかを考えると、想像してみてください:)
6. イベントストアのシリアルイベントとにかく落ち込んでいるイベントストア内のイベントの内容を照会することはできません。また、今後イベントに別の属性を追加することはできません。解決策は、シリアライズされたイベントの代わりにイベントをJSONオブジェクトとして保存することでしょうか？しかしそれは良いアイデアですか？または、orignalイベントオブジェクトの変更をサポートするイベントを追加しますか？

私がここで育った不利益についてコメントしてください、私が間違っていて、他の人が私が逃したかもしれないと示唆してもらえますか？

Answer 1

これが私の考えです。

1. CQRS + ESは、豊富なドメインオブジェクト、単純なデータモデル、履歴追跡、並行性の問題、スケーラビリティとはるかに多くの可視性を持つことにより、複雑なソフトウェアシステムではずっと簡単なものを作ることができます。システムに関して考え方を変える必要があるため、資格のある開発者を見つけるのが難しいかもしれません。しかし、CQRSを使用すると、開発者間で責任を分けることが簡単になります。たとえば、ジュニア開発者は、ビジネスロジックに触れることなく、読み込み側で純粋に動作することができます。

2. データのコピーには、より多くのディスク容量が必要です。しかし、最近のストレージは比較的安いです。 ITサポートチームは、事態が悪化した場合にシステムを復元する方法をさらにバックアップし計画する必要があります。しかし、近年のサーバー仮想化により、より合理化されたワークフローが実現します。また、モノリシックデータベースなしでシステムに冗長性を作成する方がはるかに簡単です。

3. 私は、メモリ使用量がより高いとは考えていません。ビジネスオブジェクトの水和は、オンデマンドで行う必要があります。オブジェクトは、すでに永続化されているイベントへの参照を保持すべきではありません。また、イベントのハイドレーションは、データを持続させる場合にのみ発生します。読み込み側では、通常、階層化されたシステムで発生したEntity - > DTO - > ViewModel変換はありません。フル機能のORMが通常行うようなオブジェクトチェンジトラッキングはありません。ほとんどのシステムは、書き込みよりもはるかに多くの読み取りを実行します。

4. さまざまなデータコンテキストの初期化により複数の異機種データベースを使用している場合は、起動時間が長くなることがあります。しかし、ADO.NETのようなシンプルなものを使用して、イベント・ストアと読取り側のマイクロORMを操作すると、フル機能のORMよりも「コールド・スタート」速度が速くなります。ここで重要なのは、データへのアクセス方法を複雑にすることではありません。それは実際にはCQRSが解決しようとしている問題です。前にも述べたように、読み込み側はビューをモデル化し、データを再マッピングするオーバーヘッドはありません。

5. 2フェーズコミットは、私の経験で何千ものユーザーのために拡張する必要のないシステムでうまく機能します。分散トランザクションコーディネータと連携するデータベースを選択する必要があります。 PostgreSQLは、例えば、別々のモデルの読み書きに適しています。多数の同時ユーザーのためにシステムを拡張する必要がある場合は、最終的な整合性を考慮して設計する必要があります。最終的な一貫性を避けるためにCQRSを使用しない集約ルーツまたはコンテキスト境界を持つケースがあります。ドメインの非コラボレーション部分には意味があります。

6. イベントストアに適切なデータベースを選択すると、JSONやXMLなどのシリアル化された形式でイベントをクエリできます。そして、それは分析の目的のためだけに行われるべきです。システム内部の何も、集約ルートIDとイベントタイプ以外のものでイベントストアを照会するものはありません。そのデータは索引付けされ、シリアライズされたイベントの外側に存在します。ただ、ポイント5上にコメントする

Answer 2

私はFacebookがあなたが時々ポストは消え、あなたがそれを投稿した後に再表示され見ることができる理由です結果整合性、とESを使用しないことを言われてきました。

通常、ブラウザがアクセスしている読み取りモデルは「近く」にありますが、投稿を行った後、SPAは書き込みモデルに近い読み取りモデルに切り替わります。書き込みモデル（イベント）と読み込みモデルとの間の近接性は、あなた自身の投稿を見ることを意味する。

しかし、15分後、SPAは最初の、近い、読み取りモデルに戻ります。あなたの投稿を含むイベントがまだその読み込みモデルに伝播していない場合は、自分の投稿が消えて、後でいつか再び表示されるだけです。