UdiスタイルのSOAアーキテクチャでデータをどのように集計しますか？

Question

私たちは、Udi Dahanの方法でSOAアーキテクチャを実装しています。つまり、サービスはビジネスに対応した自律型コンポーネントです（サービスはほとんどなく、それぞれドメインの一部であり、互いに呼び出すことはできません）。私たちはnservicebus pub/subを使用しています。私は、「クロスカッティング」データの問題を処理する最良の方法を理解しようとしています。

例を挙げましょう：

私たちは、ユーザーがゲームをプレイするために使用できるゲームサービスを提供しています。ゲームには締め切りがあり、ユーザーにメールを送信して締め切りを知らせる必要があります。メールには複数のサービスからのデータが含まれます。サービスは他のサービスを呼び出すことはできませんので、今、私はいくつかの異なるアプローチを参照してください。

1）ゲームサービス

でそれを扱うゲームサービスはそのを格納できるように、他のサービスから十分なメッセージを公開自分が必要とするデータを自分自身で作成することができます。したがって、メールを作成するときに他のサービスからのデータに依存する必要はありません。

短所：

-moreメッセージが（メールに複数のメッセージを、新しいデータを追加するために、データの -Denormalization -Fussyデータ所有権（複数の場所で1つの事実） -Cumbersomeを公表する必要がある、店ゲームサービスのもの）

2）集約サービスを作成します。

サービスイベントを監視し、メールを作成し、デッドラインが終了したことをゲームサービスが通知したときに消す必要があるすべてを保存する集約サービスを作成します。

短所：1とほぼ同じ

-pretty）が、データ所有権は

3もっとたくさん明確である）（このクライアントがする "クライアント" を作成し、クライアント

を作成します。 guiを持たず、nservicebusがホストされます。サービスとほぼ同じですが、まったく異なるものもあります）。クライアントはバスイベントを購読し、2）デッドラインが終了したときにゲームサービスから通知を受ける。クライアントは、必要な情報を収集するために必要なサービスを照会してメールを作成します。

短所：

-Aクライアントサービス（ファジーアーキテクチャ） は照会可能（公開）されなければならないメールを作成するために必要な-Everything

あなたはあなたの偉大なパブリッシュ/サブスクライブのUDIスタイルSOAでこれを行うましたか

建築？ :-)

Answer 1

HTMLメールを送信できるのであれば、電子メールコンポーネントに通常の構成形式のURLのHTML出力を取得させることができます。 HTMLを実行できない場合は、情報を収集するためにIT/Opsサービスが必要です（ただし、同じエンドポイントにインストールされているさまざまなビジネスサービスのコンポーネントへのインプロセス通信を介して行われます）。

Answer 2

Udi Dahan（特に最近の文章では）のオプション3が最も近いと思います。すべての情報は所有者にとどまり、クライアントは単なる集約者に過ぎません。