私は非同期メッセージングを研究しており、特定のドメイン内の問題をエレガントに処理する方法と、ドメインの概念をより明確にする方法が気に入っています。しかし、それは一般的なドメイン駆動型の開発 (少なくともサービス/アプリケーション/コントローラー レイヤー) の実行可能なパターンですか? それとも、リモート サービスや分散処理などの SOA ベースのシナリオに制限する必要があるような設計オーバーヘッドですか?
3 に答える
5
素晴らしい質問:)。非同期メッセージングの主な問題は、人々が手続き型またはオブジェクト指向言語を使用する場合、非同期またはイベントベースの方法で作業することは、プログラマーが読んで理解するのが非常に難しく複雑であることが多いことです. ビジネスロジックは、メソッドを呼び出してすぐに結果を取得するなど、同期的な方法で構築されている場合、多くの場合、はるかに単純になります:)。
私の経験則では、一般的に、ビジネス ロジックのミクロ レベルでより単純な同期プログラミング モデルを使用してみます。次に、非同期と SEDA をマクロ レベルで使用します。
たとえば、発注書を送信すると、メッセージ キューにメッセージが書き込まれるだけです。しかし、発注書の処理には、10 の異なるステップが必要になる場合があります。これらはすべて、多数の同時プロセスとスレッドが個々のステップを並行して処理する高性能分散システムで非同期かつ並列です。したがって、マクロ レベルの配線は SEDA のようなアプローチに基づいていますが、ミクロ レベルでは、個々の 10 ステップのコードはほとんどが同期プログラミング スタイルで記述できます。
于 2008-09-16T16:01:12.723 に答える
2
非常に多くのアーキテクチャと設計に関する質問と同様に、答えは「場合による」です。
私の経験では、非同期メッセージングの強みは、それが設計にもたらす疎結合にあります。カップリングは次のとおりです。
- 時間 - リクエストは非同期で処理できるため、全体的なスケーラビリティが向上します。
- スペース - ご指摘のとおり、多くの同期設計よりも堅牢な方法で分散処理を可能にします。
- テクノロジー - メッセージとキューは、テクノロジーの違いを橋渡しする 1 つの方法です。
メッセージとキューは、さまざまな実装を持つことができる抽象化であることを思い出してください。JMS 準拠のトランザクション対応の高性能メッセージング フレームワークを必ずしも使用する必要はありません。正しく実装すると、リレーショナル データベース内のテーブルは、行をメッセージとして持つキューとして機能できます。私は、両方のアプローチが大きな効果を発揮するのを見てきました。
于 2008-09-16T16:11:47.970 に答える
1
ところで@BradSにも同意します
ところで、これはビジネス ロジックからミドルウェアを隠す方法ですが、疎結合と SEDA の利点を引き続き得ながら、インメモリ SEDA から JMS、AMQP、JavaSpaces、データベースまで、さまざまな異なるミドルウェア テクノロジ間を簡単に切り替えることができます。ファイルまたは FTP など
于 2008-09-16T18:06:44.980 に答える