首先，我不完全确定我理解你的问题，所以让我陈述我的假设，然后提供我的答案。根据需要进行调整。
假设：
- 您的业务流程模型操作集。示例：A 可以是结帐步骤，C 和 C' 是两个不同但相似的付款步骤。
- 每个处理步骤都对公共数据集的不同部分进行操作。示例：B 计算总计和折扣（对购物车内容进行操作），C 和 C' 计算总计并发起某种付款。
- 您希望尽可能地保持现有实现的完整。
如果是这种情况，我会确保我对我的数据模型有正确的理解，以及每个步骤将在哪些部分上运行，然后围绕它构建一个状态机。
好处：
- 您的每个流程步骤都可以使用一种或多种状态进行建模。您确保转换基于数据模型。您可以有一个决策状态，该状态基于用户使用 Paypal 付款或兑换代金券的决定，将您转换到适当的状态来处理此问题。
- 状态可以单独测试。单元测试将很容易编写，并且您可以为面向客户的功能构建工具以进行手动测试（例如与支付提供商的集成测试）。
- 状态机通常占用空间小。它们通常是事件驱动的，因此在您的应用程序中保持线程计数。如果状态只包含逻辑并且只对数据对象进行操作，您甚至可以跨不同的并发进程重用状态实例。这取决于您的状态机框架。
要记住的事情：
- 在您的状态中明确，并让许多小状态执行小型专用操作。如果决定使用卡支付或代金券，则将其建模为伪状态。
- 避免上帝对象（即包含无所不知的对象）。如果状态开始在域模型的大部分上运行，请考虑改进模型或状态机
- 确保使所有内容都是事件驱动的和异步的。同步状态机无法扩展。如果您正在调用非异步服务，请为其构建一个包装器。
我在之前的项目中成功地采用了这种方式对业务流程进行建模。这是最终用户可以购买对象的流程。我们需要处理许多替代流程，例如在不同支付方式之间切换、在后端系统不可用时重试等等。
为此，我们推出了自己的状态机框架以满足我们的需求。你可能应该看看你的平台有什么可用的。