architecture - N 层架构中的事务边界

Question

我有一个 3 层架构，大致如下所示:

客户 -> 业务 -> 数据

理想情况下，交易应该从哪里开始？

一种学派认为事务应该只从数据层的顶部开始。业务层只操作有业务逻辑的业务对象，从不知道事务。业务完成其所有工作来操作对象，然后将它们交给数据层进行持久化。这是一种适用于较低层的 RESTful 哲学。

另一个学派认为事务应该从业务层的顶部开始。业务层定义逻辑工作单元，而不是数据层，因为逻辑工作单元有时包含业务逻辑，而不仅仅是数据逻辑。

我确实喜欢尽可能降低交易问题的想法。但我也发现，尝试将业务逻辑保留在数据层之外可能需要额外的努力和设计挑战，除非它只是 CRUD 操作。如果您使用大锤应用 RESTful 设计模式，则可以使您的应用程序具有很少的非 CRUD 操作。

甚至还有第三流派认为客户可以启动事务，以便在需要时可以组合多个业务操作。但是现在客户端正在定义工作单元？这不是商业问题吗？

第四流派认为我的客户端可以只是 SOA 组件，它们可以参与甚至在客户端外部启动的 XA 事务!!

我们的开发人员想要一些更具体的标准，而不仅仅是“随心所欲地开始交易”

有没有人对这个问题有任何意见或建议？

谢谢!

Answer 1

事务是一个业务概念，它应该在业务层内部进行协调。

孤立地操作对象通常没有什么好处，跨越多种类型的对象之间的操作已经是一个事务。所以第一流派是处理非常基本的案例。

当您的业务层处理事务时，谁开始事务并不重要:客户端或其他服务。此外，只有当业务层知道它们时才能支持长时间运行的(分布式)事务。