建设招投标服务的设计思路需要帮助

Question

我有一个用我正在重写的过程风格编写的遗留服务。我首先想提高可维护性；随着业务规则的变化，代码经常会被修改。因此，我希望将许多东西解耦，尽可能地将逻辑封装在它们自己的对象中，并使测试更加容易。

我正在寻求帮助，在如何思考高层设计，以便作出这些改进。

当前服务描述

该服务基本上匹配项目和投标人。它每分钟有几十次这样做。因此，在这一过程中，项目和投标人的可用性都在迅速变化。

约束条件

• 可能有1到N的匹配过程同时运行(N目前小于50，但我们希望业务增长)。
• 每个匹配的“运行”必须在1秒内完成。
• 可能有数以万计的潜在项目可供选择(并非所有的项目在任何给定的点上都有资格，例如，通常更接近一千项)。
• 可能会有上百个投标者。
• 一旦一个项目被“赢得”，它将从进一步的考虑中删除，直到它在将来的某个时候被重新储存。
• 投标人对他们可以投标的项目有不同的限制，因此有一些重要的逻辑需要对每个项目的投标人进行适当的资格认证。

过程大纲

由于上述约束，当前的过程代码类似于以下大纲：

1. 从数据库中抓取并保留100个潜在项目。
2. 循环遍历寻找缓存项的100个项的列表。(具有匹配的投标人的项目在全面评估后缓存，如下所示。)如果找到缓存项，发送到bidder，将整个工作集释放回数据库。完成了。(未来的改进，评估保留列表中的项目，以构建未来的缓存。)b.如果没有找到缓存项，请继续。
3. 循环通过项目清单，充分评估项目和投标人: a.项目是否仍然可用？如果没有，下一项。(转到3) b.否则，获取资格预审bidders的列表。
4. 是否有资格预审的bidders？a.不。循环遍历链接到初始项的“相关项”，并查找每个项目的预限定bidders。完成后就会掉下去。是的。循环通过预合格的list的bidders.
5. 合格的投标人是否有当前的合同信息？a.不。从bidder list中删除。是的，下一个bidder。

此时，我们有一个项目和一个可以接收该项目的bidders列表(可能为零长度)。只有很少的最后检查才能完全符合bidder的条件。

请记住，我们仍然处于从(2)开始的大循环中，在保留的、工作的100项工作集合中循环。

1. 如果bidders仍保留在资格预审bidders list中，则将该项目发送给这些bidders以供其最终批准。继续查看项目列表的其余部分，并缓存与bidders的任何进一步成功匹配。如果任何剩余的最后检查失败，发送状态代替实际项目。
2. 检查项目列表中的所有项目后，释放数据库保留。

Thoughts

让我难以思考和封装的是，在工作集的循环过程中，行为可能会发生很大的变化。最初的代码有语句来打破循环中的多个级别的循环。它经过了一些修改，以使用一对指示状态的标志，但它仍然非常复杂。

因为它必须是快速的，而且数据过时之前的时间很短，所以我很难想出如何封装和解耦这一点。

编辑添加

以下是对好的问题的答复：

• 循环过程是由人在网页中的点击开始的。这是“我准备好了下一个我必须管理的事务”的指标。因此，循环实际上是管理为每个用户查找下一个事务的一种方法。
• 100记录保留是一个可调的，是通过测试其他值来达到的。大约100提供了最好的性能定义的最小数量的墙上时钟时间返回匹配的项目，并出价给有关的人。

人们可以想象，人们作为拍卖人，或作为销售人员，他们拿走了物品，最后确定了销售安排。在最重要的情况下，他们必须与商品销售者口头交谈以确认他们的细节，也必须与买方进行简短的交谈以确认销售。

数字50是这些销售人员在任何时候所涉及的最大人数的总和。

关于并行性:这是一个web应用程序，所以每个评估过程都是由其中一个销售人员点击一个网站来启动的，其中通常有2到50个(当前)。

Answer 1

我认为OO可以做到这一点，其他方法也是如此。正如所写的，似乎只有两件事驱动了你的所有逻辑：

• 采取行动的人(出价、撤回、价格变动等)
• 时间(拍卖结束)

因此，除了拍卖到期、拍卖即将结束的电子邮件等基于时间的东西之外，没有必要不断地运行一个过程循环(相当于轮询)。其他一切都可以基于用户的行为来驱动事件。如果您将有状态类与那些“做事情”的类分开，您将能够更容易地进行水平扩展。

不知道为什么你的祖先把事情搞得太复杂了。或者你遗漏了一些元素，或者我没有欣赏到。如果是这样的话，我将尝试根据您的更新进行相应的修改。

这似乎是一个有趣的地方，您可以提高代码质量、性能和可伸缩性。祝你好运，玩得开心！

探索的想法:一个进程向队列中添加要“管理”的项。用户启动的进程从队列中提取要“管理”的项。这将使您更容易地扩展时间限制逻辑。

Answer 2

我不认为这是一个应用OO的好应用程序，不管它是不是，我不认为你会得到很多关于顶级OO设计模式的帮助。

现有的系统非常复杂，具有并行性和复杂的逻辑，并且已经演变成一种可能没有人完全理解的方法: 100条记录被抓取和锁定--为什么100条? 50条并行匹配任务进行这种抓取--为什么50条高速缓存的记录比非缓存的更喜欢(并不完全是一条业务规则)。

我断言，从新的顶级设计开始，您将无法复制现有的系统行为，这可能是应用OO的最全面/最完整的方式。

有人知道系统在匹配不同参数方面是否会做得更好吗?对于匹配的质量，您有什么样的测试?如果没有，我首先要做的是。由于性能限制，您是否会把更好的匹配放在桌面上?我们如何描述匹配质量与匹配速度之间的权衡？

您的系统具有很大的并行性，而OO并没有真正解决这个问题。如果您正在寻找某种替代方案，我将研究整个体系结构，特别是并行(50个并发作业和100个. )--我会问关于分布式系统与单个大内存服务器之间的问题来处理整个负载。如果需要分布式系统，可以做什么样的切分来最小化服务器之间的提交和锁定？

关注顶级设计是正确的:虽然我不会有一个将系统转换为面向对象的目标，但我会寻求通过广泛的体系结构方法来改善结果的功能质量以及非功能性能方面，并通过测试来验证改进。如果OO随之而来，那么很棒--尽管从根本上说，您需要一个可以理解的、性能良好的体系结构和设计(可能是OO或其他什么东西来帮助实现这一点)。