2017-10-12 12 views
0

SendEmailコマンドを提供するEmailerマイクロサービスを開発したいと考えています。イベントソーシングと削除可能データの組み合わせ

集計Email

  • EmailCreated
  • EmailDeliveryStarted
  • EmailDeliveryFailed
  • EmailRecipientDelivered 1 microservice内部で私は次のイベントで電子メール全体のプロセスを表し、心の中で集計を持っています受信者のメールアドレス
  • EmailRecipientDeliveryFailed受信者の1人は、電子メール
  • などのメール配信サービスSendGridが使用されている背景には

を受け取ることができませんでした。私のマイクロサービスは、自分自身のイベントでそのファサードのように機能します。 SendGridからの着信webhookは、適切なドメインイベントに変換されます。

  1. コマンドSendEmail ==>EmailCreated

  2. EmailCreatedHandler ==> Eメール:

    プロセスは次のようになります。もちろんSend(SendGridへ)

  3. 着信ウェブフック==>EmailDeliveryStarted

  4. さらにウェブフック==>EmailRecipientDeliveredEmailRecipientDeliveryFailedなど

私は外部のWebサービスを交換したいと思います場合と私はそれに適応する他のメッセージング戦略を適用しますが、私のドメインモデルはイベントで保持します。クライアントに具体的なメール配信戦略について心配する必要はありません。

私が直面する重大な問題:SendGridがすぐに利用できない場合でも、SendEmailコマンドを受け入れたいと思っています。メールデータ全体(添付ファイル付き)を保存してからイベントハンドラを起動する必要があります。送信プロセス。一方、私は最初のEmailCreatedイベントをこのBLOBデータで膨らませたくありません。そして、私はSendGridが私の電子メールの要求を受け入れた後にこのデータを整理できるようにしたい。

また、SendEmailコマンドにSendGridに電子メールを送信し、最初にEmailDeliveryStartedイベントを格納することもできます。しかし、これは、2フェーズ・コミットのように感じている:SendGridは私のコールを受け入れたが、何とか私のリポジトリは何かが間違っていたことをクライアントに通知されるだろうEmailDeliveryStartedイベントを保存することができませんでしたし、それが災害だろうどの再びしようとした場合。

だから私は私の集計を設計する方法がわからないと、それは、添付ファイルなどのBLOBデータを含むべきではありませんので、より重要なのは、私のEmailCreatedイベント。

答えて

0

私はこの質問を面白いと思っており、それを少しでも反映しています。

まず最初に、私はイベントに電子メールの添付ファイルを保存する義務はありません。添付されたファイルの完全修飾名を格納するだけで済みます。そうすれば、イベントログが小さくなり、イベントを「削除」する必要性が排除されます(イベントソースモデルでは、そうしないでください)。

第2に、プロジェクトが電子メールクライアントを構築していないと仮定すると、電子メールを集約ルートとしてモデル化する必要はありません。私は、AggregateRootsがビジネス関連のドメインを表しているのを見ています。電子メールを送信するようなユーティリティタスクではありません。送信されたものとまだ送信されていないものを追跡するデータベーステーブル/ドキュメントを使用して、これをモデル化することができます。私は、確かに追跡されるビジネスイベントへの反応としてSendGridを介して電子メールを送信することを見ていますが、それ自体のAggregateRootではありません。

最後に、SendGridがオフラインのときにもSendEmailコマンドを受け入れる場合、集約はEmailQueuedイベントを発行します。 EmailQueuedHandlerは、プロセスの読み込みモデルに、待ち状態のすべての電子メールを取得し、送信用にバッチ処理する行を生成します。 SendGridとの通信が失敗した場合は、次のいずれかです。

  • 何もしない、送信者のプロセスは(もし再試行回数が増加しますHandlerによって傍受EmailSendFailedを放ち次の試行
  • 、で電子メールを選択しますあなたはいくつかの再試行の後に停止したい)。

あなたのプロジェクトでは、十分に明確で幸運なことを望みます。

関連する問題