正しいデザインパターンを選択する際に助けが必要

Question

私たちは主導的な事業に携わっています。リードを獲得し、いくつかのルールに基づいて顧客に渡します。 APIの性質のような本質的に各クライアントへの統合は、データマッピングも必要です。リードをクライアントにルーティングするために、次の手順を実行します。

1. 任意のクライアント固有のマッピング（マスターデータ）が必要とされている場合、クライアント
2. チェックを選択します。最寄りの利用可能ディーラー（オプションのステップ）
3. コールクライアントAPIへ
4. 送信リードは、データベースへのステップのいくつかは任意でできること

注意をリードする

更新のプッシュのステータスをリード送信します。

どのデザインパターンがこの問題を解決するのに適しているか。その目的は、各クライアントへの統合を単純化することです。

Answer 1

データマッピングとAPIのように、クライアント間で異なる側面を分離（できれば外部化）し、可能な限り一般化したいと思うでしょう。考慮すべき1つの可能性は、将来どのように新しいクライアントとそのAPIを簡単に収容できるかということです。

多くのクライアントと、このクライアントリストを保持するデータベースまたはその他の永続的なメカニズムがあると仮定します。したがって、リードをクライアントにマップするデータ駆動型ルーティングロジックは問題ではありません。アプリケーション自体は、できるだけ "ダム"にする必要があります。

データマッピングは、メタデータで簡単に記述でき、データ駆動も容易です。メタデータのマッピングはクライアント固有のものであるため、XMLやその他の形式で各クライアントに関連付けられたデータベースに簡単に保存できます。特定のAPIに準拠するために必要なリードへの変換が非常に複雑な場合は、戦略パターンを使用してターゲットクライアントに応じて特定の戦略を選択してロジックを分離できます。非常に多数のクライアントとAPIを収容する必要がある場合は、APIをデータ駆動型にするために後方に曲げます。いくつかのクライアントタイプ（たとえば、20未満）がある場合は、分散非同期性を採用し、クライアントタイプに対応するトピックにリードとクライアント情報を公開し、各クライアントタイプは自分のことを行い、別の単一のキューに結果を公開します。結果待ち行列に対する消費者のリストは、データベースを更新する。

1）異なるクライアントとのAPIの統合：

Answer 2

は、私は下記の三つの部分にあなたの問題文を分割します。 2）リードをクライアントにルーティングするためにいくつかの手順を実行します。 3）データベースへのリードのプッシュ状態を更新します。三つの部分の上で関与

デザインパターン：

1）異なるクライアントとのAPIの統合 - 各クライアントへの統合は、APIの性質のような性質が異なります。互換性のないタイプのインターフェイスがあるようですので、このセクションは「アダプタデザインパターン」を使用して設計する必要があります。

2）リードをクライアントにルーティングするためにいくつかの手順を実行します。実行手順が異なります。次のステップは前のステップに基づいています。したがって、 "State Design Pattern"を使用してこのセクションを設計する必要があります。

3）データベースへのリードのプッシュステータスの更新：このステートメントは、リードのプッシュステータスが発生したときにデータベースに通知し、情報がデータベースに更新されるようにすることを示します。したがって、このセクションは "Observer Design Pattern"を使用して設計する必要があります。

Answer 3

このようなサウンドはワークフローレルムに該当します。 Amazon Webサービスを使用している場合、SWFがあります。それ以外の場合は、お気に入りのプログラミング言語のためのワークフローソリューションがたくさんあります。