Performance 如何处理其他业务流程

我的应用程序有许多模块，原始业务流程如下所示：

A->B->C->D

随着应用程序的增长，将添加替代流以满足客户的需求：

A->B->C->D

A->B->C'->D（C现在可以执行可选操作）

A->D

A->D'（D现在可以执行C的可选操作）

单元测试用例和QC手动测试的数量

目前我有两种解决方案：

在给D之前，从A默默地创建B，C，然后我可以保证给D的输入数量

跳过B、C，将D的输入调整为中间类型，并写入适配器以转换a->中间类型

选择的解决方案必须满足以下目标：

• 灵活的业务（针对客户）
• 高处理性能
• 维护（源代码）

---

我不知道我应该使用哪一个，或者有更好的解决方案。

首先，我不完全确定我是否理解您的问题，所以让我陈述我的假设，然后提供我的答案。根据需要进行调整

假设：

• 您的业务流程为一组操作建模。示例：A可以是结帐步骤，C和C'可以是两个不同但相似的付款步骤
• 每个过程步骤在公共数据集的单独部分上操作。示例：B计算总额和折扣（对购物车内容进行操作），C和C'获取总额并开始某种形式的付款
• 您希望尽可能保持现有实现的完整性

如果是这种情况，我将确保正确理解我的数据模型，以及每个步骤将在哪些部分上操作，然后围绕此构建一个状态机

好处：

• 您的每个流程步骤都可以使用一个或多个状态进行建模。确保转换基于数据模型。您可以有一个决策状态，该状态基于用户使用Paypal付款或兑换凭证的决策，将您转换到适当的状态以处理此问题
• 状态可以单独测试。单元测试将很容易编写，您可以为面向客户的功能构建工具，用于手动测试（例如与支付提供商的集成测试）
• 状态机通常占用空间小。它们通常是事件驱动的，因此在应用程序中保持线程倒计时。如果状态只包含逻辑并且只对数据对象进行操作，那么您甚至可以跨不同的并发进程重用状态实例。这取决于您的状态机框架

要记住的事情：

• 在您的状态中要明确，让许多小状态执行小的专用操作。如果决定使用卡支付或凭证，则在伪状态下对此进行建模
• 避免使用神的物体（即包含无所不知的物体）。如果国家开始对域模型的大部分进行操作，请考虑改进模型或状态机
。
• 确保所有内容都是事件驱动和异步的。同步状态机无法扩展。如果您正在调用非异步服务，请为其构建一个包装器

我在以前的项目中成功地使用了这种建模业务流的方法。这是一个最终用户可以购买物品的流程。我们需要处理许多可选流程，例如在不同的支付方式之间切换，在后端系统不可用时重试，等等

---

我们为此推出了自己的状态机框架，以满足我们的需要。您可能应该看看您的平台有哪些可用功能。

听起来您需要一个工作流系统。您可以构建各个组件并独立测试它们，然后使用工作流系统将它们连接到每个客户的配置中

---

Windows Workflow和任何Java BPM软件都适合此任务。

谢谢您的建议，但我正在开发的应用程序已经有5年的历史了，因此我在新技术方面没有选择。您通常可以将抽象放在系统中的任何边界上。我们最近将Windows工作流与一个应用程序集成在一起，该应用程序有15年的COM历史，有9年的.Net历史