過去6か月の学習曲線は、CQRSとDDDが主な原因であるため困難でした。
それは楽しかったです、そして私達は私達のプロジェクトの半分の道を進んでいます、そして私が掘り下げる時間がなかった領域はメッセージングフレームワークです。
現在、私はDTCを使用していないため、読み取りモデルが更新されていない場合、読み取りデータベースと書き込みデータベースの間に不整合が生じる可能性が非常に高くなります。また、私の読み取りデータベースと書き込みデータベースは同じマシン上にあります。それらを別々のマシンに置くことはないと思います。
私のシステムには大量のメッセージがないので、私の懸念はシステムの一貫性と信頼性に関係しています。
それで、NServiceBusのようなメッセージングフレームワークを配置する必要がありますか（読み取りデータベースと書き込みデータベースの両方が同じマシン上にある場合でも）、または他のオプションがありますか？はい、学習曲線はありますが、それを使用しないと、学ぶことがたくさんあると思います。
また、必要がなければレイヤーを入れたくない
考え？
現在、私はDTCを使用していないため、読み取りモデルが更新されていない場合、読み取りデータベースと書き込みデータベースの間に不整合が生じる可能性が非常に高くなります。
個人的には、DTCが嫌いで、避けようとしています。代わりに、特に結果整合性がすでに受け入れられ、更新がべき等である読み取りモデルのようなものに対して、補償メカニズムを実装することがしばしば可能です。たとえば、エンティティにバージョンを実装し、バージョンが同期していることを確認するバックグラウンドタスクを設定できます。DTCを使用すると、トランザクションの再試行機能が提供されますが、再試行後に障害が発生した場合は解決されません。エラーログを監視し、エラーを処理するための手順を用意する必要があります。
それで、NServiceBusのようなメッセージングフレームワークを配置する必要がありますか（読み取りデータベースと書き込みデータベースの両方が同じマシン上にある場合でも）、または他のオプションがありますか？
それはいくつかのことに依存します。CQRSシステムでよく遭遇するのは、複数のサブシステムがクエリ/キャッシングシステムがサブスクライブするイベントを公開するpub/subの必要性です。基本的なポイントツーポイントメッセージングを超えたpub/subの必要性を感じた場合は、NServiceBusのようなものを使用してください。また、スケーラビリティの目的でNServiceBusが必要ない場合でも、論理パーティショニング自体が有益であると思うので、すぐにNServiceBusの使用を躊躇することはありません。一方、ご指摘のとおり、複雑さのレイヤーを追加するにはコストがかかるため、最初に、可能な限り単純なものが機能するかどうかを確認してください。
もう1つの質問は、別のクエリストアが必要かどうかです。あなたが持っているのが単一のマシンだけであるなら、なぜわざわざするのですか？読み取りモデルパターンのような単純なものを使用しても、CQRSの多くの利点を享受できます。
CQRSプロジェクトにはNServiceBusのようなメッセージングフレームワークが必要ですか？
簡単な答え：いいえ。
eulerfxが言及した「read-modelpattern」について聞いたのは初めてです。これは十分に良い名前ですが、もう少しあります。
'query'部分の背後にある一般的な考え方は、データの非正規化ビューをクエリすることです。「read-modelpattern」リンクでは、read-modelにデータを入力するために使用されるクエリがある程度のリフティングを行っていることに気付くでしょう。上記の例では、必要なデータ操作はそれほど複雑ではありませんが、さらに複雑になった場合はどうなりますか？これが非正規化の出番です。「コマンド」の部分を実行するとき、次のアクションはデータを非正規化し、読みやすいように結果を保存することです。すべての面倒な作業は、ドメインが行う必要があります。
これがあなたがメッセージについて尋ねている理由です。ここにはいくつかのテクニックがあります：
それがストレージです。一貫性はどうですか？：
最も簡単な解決策（クイックウィン）は、ドメイン内のデータを非正規化し、リポジトリを介してドメインオブジェクトを保存した後、すぐに非正規化されたデータを同じデータストア、同じテーブル、異なる列に保存することです。100％一貫しており、非正規化されたデータの読み取りをすぐに開始できます。
本当に必要な場合は、そのデータを転送するための個別のオブジェクトの束を作成できますが、データアクセスフレームワークによって提供されるデータを運ぶオブジェクトを返す単純なクエリレイヤーを作成する方が簡単です（.Netの場合はDataRow/になりますDataTable）。絶対に空想する理由はありません。常に例外がありますが、それから先に進んでデータコンテナを書くことができます。
結果整合性を得るには、何らかの形式のキューイングと関連する処理が必要になります。独自のソリューションを展開することも、サービスバスを選択することもできます。それはあなたとあなたの時間/技術的制約次第です:)
ところで：私はここに無料のオープンソースサービスバスを持っています：
どんなフィードバックでも歓迎されます。ただし、古いサービスバス（MassTransit / NServiceBusなど）でもかまいません。
お役に立てば幸いです。