サガ、プロセスマネージャー、ドキュメントベースのアプローチの違いは何ですか？
私が理解しているのは、3つの概念はすべて、長期実行トランザクションに関連しているということです。
プロセスマネージャーは、私の理解では、イベントに反応してコマンドを発行するだけの有限状態マシンです。ビジネスロジックは含まれず、ルーティングのみが行われます。その目的は、トランザクションが成功または失敗したことを知っている最終状態にあなたを導くことです。
ここまでは順調ですね。
しかし、今私の理解の問題は始まります：
- プロセスマネージャーと対照的なサガとは何ですか？
- CQRS sagas-私はそれらを正しく理解しましたか？ で説明されているように、ドキュメントベースのアプローチもあります。私が理解しているように、ドキュメントはメモを取って手に取る「紙切れ」にすぎませんそれの周り。それはコマンドとイベントの概念にどのように適合しますか？
誰もが違いを説明できますか-私が特に興味があるのは-これらのコンセプトのどれが何に適しているのか、いつ必要なのかそれらは相互に排他的ですか？あなたはそれらのうちの1つだけでずっと行くことができますか？複数必要なシナリオはありますか？ …？
プロセスマネージャーと対照的なサガとは何ですか？
これらのパターンの意図は異なります。プロセスマネージャーは、あなたが言うように、ステートマシンの上に構築できるワークフローパターンです。プロセスマネージャはメッセージ間で状態を保持し、メッセージに応答して実行する必要があるアクション（たとえば、状態の移行や別のメッセージの送信など）を決定するためのロジックを含みます。一部のフレームワークは、これらをsagasと誤って参照します。
対照的に、サガ（元の定義による）は、障害の管理に役立つことを目的としたパターンです。システム全体に複数のワークフローが含まれ、それぞれが何らかの形で補正アクションを実行できるようにします後のトランザクションで他の場所で障害が発生した場合。
この報酬は、佐賀の特徴的な特徴です。サガ自体は知らないことに注意してくださいwhat代償アクションがそうであるかもしれません。 Sagasは、ルーティングスリップパターンを使用して実装されることがよくあります。
それらは相互に排他的ですか？あなたはそれらのうちの1つだけでずっと行くことができますか？
これらは相互に排他的ではありません。たとえば、サガに参加しているシステムがプロセスマネージャを使用して実際にその処理を処理する可能性があります。
その他のリソース
これらの投稿の一部は、より詳細な情報と例を提供するのに役立ちます。
MSDNのCQRS Journeyプロジェクトをご覧ください。
http://msdn.Microsoft.com/en-us/library/jj591569.aspx
用語の明確化
サガという用語は、CQRSの説明で一般的に使用され、境界のあるコンテキストと集約の間でメッセージを調整およびルーティングするコードの一部を指します。ただし、このガイダンスでは、この種のコードアーティファクトを指すのにプロセスマネージャーという用語を使用することをお勧めします。これには2つの理由があります。
CQRSに関連して一般的に理解されているものとは異なる意味を持つ、サガという用語のよく知られている既存の定義があります。プロセスマネージャという用語は、このタイプのコードアーティファクトによって実行される役割をより適切に説明したものです。
サガという用語はCQRSパターンのコンテキストでよく使用されますが、既存の定義があります。このガイダンスでは、この既存の定義との混乱を避けるために、プロセスマネージャーという用語を使用することを選択しました。
分散システムに関連する「佐賀」という用語は、Hector Garcia-MolinaとKenneth Salemによる論文「Sagas」で最初に定義されました。このホワイトペーパーでは、長期実行ビジネスプロセスを管理するために分散トランザクションを使用する代わりに、佐賀を呼び出すメカニズムを提案します。このペーパーでは、ビジネスプロセスは多くの場合複数のステップで構成されており、それぞれにトランザクションが含まれること、およびこれらの個々のトランザクションを分散トランザクションにグループ化することで全体的な一貫性を実現できることを認識しています。ただし、実行時間の長いビジネスプロセスでは、分散トランザクションの使用中にロックを保持する必要があるため、分散トランザクションを使用すると、システムのパフォーマンスと同時実行性に影響を与える可能性があります。
佐賀県にはプロセスマネージャーの状態がありません。
もう1つの違い-プロセスマネージャーはステートマシンですが、佐賀はそうではありません。
佐賀県にない
- 状態機械の状態
- データ状態（一部の永続データ）
..そしてプロセスマネージャーは
- 状態機械の状態
- データ状態（一部の永続データ）
私のブログでもっと読む： http://blog.devarchive.net/2015/11/saga-vs-process-manager.html
SagaとProcess Managerは2つの統合パターンです。それらは非常に似ていますが、全体ではありません。
- Sagaは、複数のサービスにまたがる各ビジネストランザクションをサガとして実装するのに役立つパターンです。実際、一連のローカルトランザクションを作成します。各ローカルトランザクションはデータベースを更新し、メッセージまたはイベントを発行して、サガの次のローカルトランザクションをトリガーします。サガを実装するには、2つの方法があります。オーケストレーション（オーケストレータが参加者に実行するローカルトランザクションを指示する）とコレオグラフィ（各ローカルトランザクションは、他のサービスでローカルトランザクションをトリガーするドメインイベントを発行する）です。 Sagaを使用するとCQRSとEventSourcingの使用法が決まることは非常に一般的です。
- Process Managerは、シーケンスの状態を管理し、中間結果に基づいて次の処理ステップを決定するために存在する処理ユニットです。これはルーティングパターンです。それはオーケストレーター佐賀のようなものです。
プロセスマネージャーとサガの両方が、必要な手順が設計時にわからない場合や連続していない場合に、複数の処理手順を介してメッセージをルーティングします。
プロセスマネージャパターンは、プロセス固有のロジックをカプセル化し、プロセスが完了したら次に何を実行するかを決定する制御の中心点を維持する、耐久性のあるイベントスケジューラです。プロセスマネージャーは状態を維持するため、たとえば、顧客から支払いがあった場合、注文を送信する必要があるという事実はプロセスマネージャーに保持されます。
Saga managerパターン。プロセスが完了したら、次に何を実行するかを決定するプロセスロジックをカプセル化します。サガは状態を保持しないので、着信メッセージまたはイベントの内容に完全に基づいて次に何をするかを決定します。したがって、支払いがプロセスによって行われる場合、そのプロセスは、何を誰に送信する必要があるかを含め、注文を送信する必要があることを示す新しいメッセージも作成します。メッセージには追加の支払い情報も含まれているため、注文の送信で問題が発生した場合は、返金されます。