通知システムマネージャーを作成する必要があります。
私の要件は次のとおりです。
異なるプラットフォームで通知を送信できる必要がありますが、これは完全に異なる場合があります（たとえば、SMSまたはEメールのいずれかを送信できる必要があります）。
通知は、特定のプラットフォームのすべての受信者で同じ場合もありますが、プラットフォームごとの受信者（または複数）ごとの通知である場合もあります。
各通知にはプラットフォーム固有のペイロードを含めることができます（たとえば、MMSにはサウンドまたは画像を含めることができます）。
システムはスケーラブルである必要があり、アプリケーションまたはサーバーをクラッシュさせることなく、非常に大量の通知を送信できる必要があります。
これは2段階のプロセスです。最初に顧客がメッセージを入力し、送信先のプラットフォームを選択します。その後、リアルタイムで処理されるように通知を作成する必要があります。
次に、システムはプラットフォームプロバイダーに通知を送信する必要があります。
今のところ、私はいくつかの結果になりますが、どれだけスケーラブルであるか、またはそれが良いデザインであるかどうかはわかりません。
私は次のオブジェクトを（疑似言語で）しました：
汎用Notificationオブジェクト：
class Notification {
String $message;
Payload $payload;
Collection<Recipient> $recipients;
}
次のオブジェクトの問題は、受信者が1.000.000だったらどうなりますか？Recipientオブジェクトが非常に小さい場合でも、メモリを大量に消費します。
受信者ごとに1つの通知を作成することもできますが、一部のプラットフォームプロバイダーはバッチで送信する必要があるため、複数の受信者で1つの通知を定義する必要があります。
作成された各通知は、DBやRedisなどの永続ストレージに保存できます。
これを後で集約してスケーラブルであることを確認するのは良いことでしょうか？
2番目のステップで、この通知を処理する必要があります。
しかし、適切なプラットフォームプロバイダーへの通知をどのように区別できますか？
をMMSNotification拡張するようなオブジェクトを使用する必要がありabstract Notificationますか？または何かのようなNotification.setType('MMS')？
大量の通知を同時に処理できるようにするには、RabbitMQのようなメッセージングキューシステムが適切なツールであると考えています。それは...ですか？
これにより、大量の通知をキューに入れ、複数のワーカーに通知をポップして処理させることができます。しかし、上記のように受信者をバッチ処理する必要がある場合はどうなりますか？
次に、プラットフォームプロバイダーを接続して通知を実行するために、それぞれNotificationProcessor追加できるオブジェクトを担当することを想像します。NotificationHandlerNotificationHandler
を使用しEventManagerて、プラグイン可能な動作を許可することもできます。
フィードバックやアイデアはありますか？
お時間をいただきありがとうございます。
注：私はPHPでの作業に慣れており、おそらく選択した言語です。
編集 （morphunrealの答えによる）
- 1秒間に送信するメッセージの数（現在/初期レベルを定義し、再設計する前にシステムが処理する必要がある最大レベルを定義します）
- システムのハードウェア制約（システムで使用可能なメモリ、CPUなど）
- ハードウェアはどのように拡張されますか（つまり、サーバーの追加、クラウドコンピューティングなど）
- どの言語/システムが通知を生成しますか？
通知はプログラムで作成しますが、UIから作成するのは私自身です。
- ジェネレーターはメッセージの受信者を知っていますか（？）、または他の手段で提供されていますか（つまり、特定のアラートタイプのビジネスルールは特定の受信者に送信されます）
特定の受信者、受信者のグループ（たとえば、タグシステムを使用）、またはプラットフォーム全体に対して通知を作成できる必要があります。
- CC / BCC /開封確認を追加するためのビジネスルールはありますか
はい。これは実際にはプラットフォーム固有であり、readまたはccはすべてのプラットフォームで利用できるわけではないことに注意してください。
- ジェネレーターは、送信するメッセージの種類（SMS /電子メールなど）を知っていますか、それとも受信者に基づいていますか
受信者に基づいていますが、受信者はプラットフォームに関連しており、プラットフォームがデータを処理する方法が異なるため、UIは画像、音声などを設定できるプラットフォーム固有のものである可能性があります。
- ジェネレーターは、メッセージの送信/受信/読み取りの確認を必要としますか（非同期送信と同期送信）
システムはエラーを起こしやすいはずですが、エラーを処理して一連のルールを定義する必要があります。たとえば、サーバーに到達できない場合は、通知を再処理してさらに処理する必要がありますが、通知が正しくない場合（またはプラットフォームプロバイダーによってそのまま定義されます）、キューに再登録するのではなく、通知する必要があります。
- メッセージの送信元/受信者の履歴を保存するための要件はありますか？
はい、私たちはおそらくいくつかの統計とレポートを作りたいです。*通知エンドポイントの定義
メッセージの送信に使用されているサービスは何ですか？依存します、いくつかは古典的なRESTウェブサービスであり、他はいくつかのエキゾチックなプロトコルです、それは実際にプロバイダー次第です。
提供されるフィードバック/確認（同期/非同期）
場合によっては、一部は同期してエラーで応答しますが、他の一部はエラーをチェックするために後でプルする必要があります。
- 新しいエンドポイントを追加する可能性がありますか[追加する場合でも、抽象化する必要があるか]
はい、実際、私たちのアプリは成長しており、新しいプロバイダーを追加できるようにしたいと考えていますが、それは1年に1つか2つの割合です。