2017-10-12 100 views
0

我們正在引領業務。我們捕捉潛在客戶並根據一些規則將其傳遞給客戶。整合到每個客戶端,就像API的性質一樣,在某些情況下,數據映射也是必需的。我們執行以下步驟以將線索路由到客戶端。需要幫助選擇正確的設計圖案

  1. 是否需要任何特定的客戶端映射(主數據)選擇客戶端
  2. 檢查。
  3. 發送導致最近的可用經銷商(可選步驟)
  4. 通話客戶端API發送導致的鉛
  5. 更新推送狀態數據庫

注意,某些步驟可能是可選的。

哪種設計模式適合解決這個問題。動機是爲了簡化對每個客戶的整合。

+0

也許你可以提出一些你一直在考慮的設計? – dm03514

+0

您知道多少個客戶?當新客戶開始處理他們的情況時,您是否創建新課程? – Amit

回答

1

你會想要隔離(最好是外部化)客戶端之間不同的方面,比如數據映射和API,並儘可能地進行概括。需要考慮的一個可能的因素是未來可以容納新客戶和他們的API。

我假設你有很多客戶端,以及一個數據庫或其他持久機制來保存這個客戶端列表,因此將數據驅動的路由邏輯映射到客戶端應該不成問題。應用程序本身應儘可能「啞」。

數據映射通常很容易用元數據描述,也很容易用數據驅動。映射元數據是特定於客戶端的,因此它可以很容易地保存在與XML或其他格式的每個客戶端關聯的數據庫中。如果爲符合特定API所需的線索轉換非常複雜,則可以通過使用策略模式來隔離邏輯,並根據目標客戶選擇具體策略。如果需要容納大量的客戶端和API,我會向後彎曲以實現API數據驅動。如果你只有少數客戶類型(比如少於20個),我會使用一些分佈式異步性,並且只是讓我的應用程序將主角和客戶信息發佈到與客戶類型相對應的主題,並且訂購了外部處理器每個客戶端類型都做他們的事情並將結果發佈到另一個隊列中。消費者列入結果隊列將更新數據庫。

0

我會將您的問題陳述分爲以下三部分:

1)API與不同客戶端的集成。 2)執行一些步驟將路線引導到客戶端。 3)更新潛在客戶的推送狀態到數據庫。

上述三個部分參與設計模式:

1)與不同的客戶端API的積分 - 積分到每個客戶端在本質上類似的API的性質而變化。看起來你有不可接受的界面類型,所以你應該使用「適配器設計模式」來設計這一部分。

2)執行一些步驟將引導線路由到客戶端 - 您有不同的執行步驟。下一步是基於前面的步驟。所以,你應該使用「狀態設計模式」來設計這個部分。

3)將導聯的推送狀態更新爲數據庫:此語句顯示,只要導致推送狀態發生,就會通知數據庫,以便將信息更新到數據庫中。所以,你應該使用「觀察者設計模式」來設計這一部分。

0

這樣的聲音屬於工作流領域。 如果您使用的是亞馬遜網絡服務,那麼就是SWF,否則,您最喜歡的編程語言有很多工作流程解決方案。