2

イベント ドリブン アーキテクチャ (EDA) の設計パターンについてよく読んでいますが、非常に強力に見えますが (あえて美しいと思いましたか?)、次の 2 つの点について混乱しています。 、例外を制御する方法。

Ajax を使用するために公開されたコールバックを設計したいとしましょう。コールバックは、「ユーザー名」と「パスワード」を使用してフロントエンドによって起動され、成功または失敗を示すローカライズされた「リターン コード」を返します。

ユーザーが正常にログインしたら、ログインして管理と電子メールを送信し、セッションを開始するとします。EDA ベースのパターンを使用していた場合、次のようになります。

ユーザー ログイン -> (常にイベントをディスパッチ) -> (ログ、電子メールの送信、セッションの開始がすべて呼び出される)

つまり、ログイン コールバックは、その特定のイベントをリッスンするすべての登録済みクラスを発行する何らかの通知をディスパッチします。私の問題は、オーセンティケーターのペア (ユーザー名、パスワード) が成功したかどうかを誰が確認しているのかということです。ある意味では、これら 3 つのイベントは、認証が正しかった場合にのみ有効です。

したがって、おそらく最初に 1 つのイベントを起動し、成功した場合にのみ他のイベントを起動します。

ユーザーのログイン -> (常にイベントをディスパッチします) -> ユーザーのログインを試みます (成功した場合はイベントをディスパッチします) -> (ログ、電子メールの送信、セッションの開始がすべて呼び出されます)

それが機能している間、私はフィードバックを得る方法を制御できなくなりました. イベントは、「設定して忘れる」一連の思考に従っているように見えます。フロントエンドにコードを返すにはどうすればよいですか? つまり、イベントオブザーバーがサブジェクトにフィードバックを与える方法がわかりません。

これは例外処理に続きます。このシナリオで例外を処理する最善の方法は?

アドバイスをいただければ幸いです。エイドリアン

(おそらく理論的な意味では問題ではありませんが、私はこれを PHP に適用しようとしています)

4

1 に答える 1

3

EDA は優れていますが、あらゆる場合にどこでも使用する必要があるという意味ではありません。EDA の目的は、デカップリングとスケーラビリティを提供することであり、これは、即時のフィードバックを持たず、最終的な整合性を処理するというトレードオフで達成されます。

また、少なくとも Web アプリでは、EDA をドメイン イベント アーキテクチャとして実装するのが最善です。つまり、これらのイベントは、ドメイン (ビジネス) に関連する何かが発生したことを伝えます。

イベントは「ファイア アンド フォーゲット」タイプであることは間違いありません。なぜなら、イベントは過去に何かを表現し、他の関心のあるコンポーネントに通知されるように公開されているからです。しかし問題は、これらのコンポーネントが他のコンポーネントやイベントのソースについて何も知らないことです。ポイントはデカップリングであることを忘れないでください。

ユーザーログインなどはドメインアクションではなく、「古い」方法で実装する方がはるかに簡単で保守可能です。また、デカップリングが必要な場合でも、それはアーキテクチャ (高) レベルのデカップリングよりも低レベルに関するものです。

于 2014-01-29T12:53:44.190 に答える