非同期メッセージング (特にパブリッシュ/サブスクライブ スタイルのメッセージング) は、ドメイン サービス アーキテクチャとして実行可能ですか、それとも SOA 中心の環境でのみ実行可能ですか?

Question

私は非同期メッセージングを研究していますが、特定のドメイン内のいくつかの問題をエレガントに処理する方法と、ドメインの概念をより明確にする方法が気に入っています。しかし、これは一般的なドメイン駆動開発 (少なくともサービス/アプリケーション/コントローラー層) で実行可能なパターンなのでしょうか、それとも設計のオーバーヘッドを考えると、リモート サービスや分散処理などの SOA ベースのシナリオに制限する必要があるのでしょうか?

Answer 1

素晴らしい質問です:)。非同期メッセージングの主な問題は、手続き型言語またはオブジェクト指向言語を使用する場合、非同期またはイベントベースの方法での作業が非常に扱いにくく複雑で、プログラマにとって読みにくく、理解できないことが多いことです。ビジネス ロジックは、メソッドを呼び出してすぐに結果を取得するなど、同期的な方法で構築すると、はるかに単純になることがよくあります :)。

私の経験則では、ビジネス ロジックには、より単純な同期プログラミング モデルをミクロ レベルで使用してみるのが一般的です。次に、マクロ レベルで非同期と SEDA を使用します。

たとえば、注文書を送信すると、メッセージ キューにメッセージが書き込まれるだけの場合があります。しかし、注文書の処理には、多くの同時プロセスとスレッドが個々のステップを並行して処理する高性能分散システム内で、すべて非同期かつ並列である 10 の異なるステップが必要になる場合があります。したがって、マクロ レベルの配線は SEDA のようなアプローチに基づいていますが、ミクロ レベルでは、個々の 10 ステップのコードはほとんどが同期プログラミング スタイルで記述できます。

Answer 2

建築やデザインに関する多くの質問と同様、答えは「状況による」です。

私の経験では、非同期メッセージングの強みは、それが設計にもたらす疎結合にあります。カップリングは次のとおりです。

• 時間 - リクエストは非同期的に処理できるため、全体的なスケーラビリティが向上します。
• スペース - ご指摘のとおり、多くの同期設計よりも堅牢な方法で分散処理が可能になります。
• テクノロジー - メッセージとキューは、テクノロジーの違いを埋める 1 つの方法です。

メッセージとキューはさまざまな実装が可能な抽象概念であることに注意してください。必ずしも JMS 準拠のトランザクション対応の高パフォーマンスのメッセージング フレームワークを使用する必要はありません。正しく実装すると、リレーショナル データベース内のテーブルは、行をメッセージとして持つキューとして機能できます。私は両方のアプローチが大きな効果を発揮しているのを見てきました。

Answer 3

ところで私も@BradSに同意します

ところで ビジネス ロジックからミドルウェアを隠す方法は次のとおりです 疎結合と SEDA のメリットを享受しながら、メモリ内 SEDA から JMS、AMQP、JavaSpaces、データベース、ファイル、FTP などに至るまで、さまざまな異なるミドルウェア テクノロジを簡単に切り替えることができます。