处理事务时提取技术细节的策略

Question

我喜欢以这样一种方式进行编程:我构建的应用程序的每个组件/可注入性，都有一个明确定义的范围，而且很容易测试。

经过多年的开发工作，我来确保我声明和实现的每个组件都符合以下类别之一：

1. 技术组件:所有工作的幕后人员。通常不是我们实现的，而是某些库的一部分。数据库连接、服务器引擎、http客户端等。
2. 业务逻辑组件:它们描述和编码业务规则，从不处理诸如Http请求解析、Db连接或数据序列化/反序列化之类的问题。(OrdersService、UsersService等)
3. 边界组件:它们处理业务意图和技术操作之间的转换(即将创建实体的意图转换为insert语句，或解析Http请求的正文，转换为业务意图，或将某些业务操作的结果编码为JSON )。DAOs/repos、控制器和API客户端通常属于这一类。

也就是说，没有任何业务逻辑组件与技术组件直接交互，而是与其他业务逻辑组件和边界组件直接交互。

现在，在编码业务规则时，应该使用业务逻辑组件，对吗？但是，如果这样的规则需要在依赖DB的事务下运行呢？

如何编码多个业务步骤，这些步骤需要在某些事务的范围内运行，而不产生泄漏的抽象？

因此，假设我想要添加付款，然后将订单状态从Pending更改为Processing

这是一个商业规则，当一个发生，另一个也必须发生。然而，这些行为属于两个不同的领域，然而，它们必须以交易方式发生.这些步骤必须编码在业务逻辑组件中，并且没有泄漏抽象，仍然表示它们属于某些事务。怎么做？

Answer 1

传统的答案是“工作单位”模式。但在我看来，这并不特别好。

更好的解决方案是取消事务。或者至少把他们从商业语言中删除。

例如，假设我们有一个业务规则：

• 只有允许新的订单被创建，如果项目是库存！

呃，哦，你认为，现在我需要以某种方式保留库存，创建订单，分配储备库存，如果有什么失败，一切都回来了！这破坏了我的对象类型系统！我有祸了！

或!你可以调整一下商业规则。我是说“创造”到底是什么意思？不是“保存到数据库”，因为业务规则不应该了解数据库，对吗？因此，您在DB中输入了“尚未创建的”状态。做你的其他部分，出错，将状态更改为“不够库存”，将队列中的消息推送回客户并更新他们的订单屏幕等等。

您会发现，您可以在分布式系统中完成整个任务，而不需要锁或事务，而且一切都很好。

Answer 2

引入工作流组件。使用此Workflow组件，我们可以在业务级别定义规则(或逻辑条件)，比如‘如果并且只有当收到付款时订单正在处理’(切线:这里我们看到了示例规则的一个问题)(规则不必是命令式的)。

使用工作流组件，我们组合和编排业务级别的操作。我们把这些作品交给技术水平来执行。

根据您希望您的业务级操作是多么孤立，技术级别要么在常规ACID DB事务中执行操作，要么要求每个业务级别操作定义一个(或多个)撤消/反向方法，然后您可以在一个saga中执行它们。