需要帮助选择正确的设计模式

时间:2017-10-12 10:38:35

标签: oop design-patterns architecture

我们正处于领先业务领域。我们根据一些规则捕获潜在客户并将其传递给客户。像API的本质一样,本质上集成到每个客户端,在某些情况下,还需要数据映射。我们执行以下步骤以将潜在客户路由到客户端。

  1. 选择客户端
  2. 检查是否需要任何特定于客户端的映射(主数据)。
  3. 将潜在客户发送至最近的经销商(可选步骤)
  4. 致电客户端api发送潜在客户
  5. 更新潜在客户对数据库的推送状态
  6. 请注意,某些步骤可以是可选的。

    哪种设计模式适合解决此问题。其动机是简化与每个客户的整合。

3 个答案:

答案 0 :(得分:1)

您需要隔离(并且最好外部化)客户端之间不同的方面,例如数据映射和API,并尽可能地进行概括。要考虑的一个可能的因素是,未来可以轻松容纳新客户及其API。

我假设您拥有大量客户端,以及拥有此客户端列表的数据库或其他持久性机制,因此将数据驱动的路由逻辑映射到客户端应该不是问题。应用程序本身应该尽可能“愚蠢”。

数据映射通常很容易用元数据描述,也很容易用数据驱动。映射元数据是特定于客户端的,因此可以轻松地将其保存在与XML或其他格式的每个客户端关联的数据库中。如果对符合特定API所必需的引导的转换非常复杂,则可以通过使用策略模式来隔离逻辑,其中根据目标客户端选择特定策略。如果需要容纳极大量的客户端和API,我会向后弯曲以使API数据驱动。如果你只有几个客户端类型(比如少于20个),我会使用一些分布式异步,并让我的应用程序将主角和客户端信息发布到与客户端类型相对应的主题,并且已经订阅了特定于每个客户端类型都做他们的事情并将结果发布在另一个队列上。列在结果队列中的消费者将更新数据库。

答案 1 :(得分:0)

我会将您的问题陈述分为以下三个部分:

1)API与不同客户的集成。 2)完成一些步骤以便将潜在客户路由到客户端。 3)更新导联到数据库的推送状态。

设计模式涉及以上三个部分:

1)API与不同客户端的集成 - 与每个客户端的集成在性质上与API的性质不同。看来你有不合适的接口类型,所以你应该使用“适配器设计模式”来设计这个部分。

2)执行一些步骤以将引导路由到客户端 - 您有不同的执行步骤。下一步是基于前面的步骤。因此,您应该使用“State Design Pattern”设计此部分。

3)更新前导到数据库的推送状态:此语句显示您希望在引导的推送状态发生时通知您的数据库,以便将信息更新到数据库中。因此,您应该使用“观察者设计模式”设计此部分。

答案 2 :(得分:0)

这听起来属于工作流领域。 如果您使用的是亚马逊网络服务,那么就有SWF,否则,您可以使用许多工作流程解决方案来获得您喜欢的编程语言。