我有一个3层架构，看起来大致如下：
客户 - ＆gt;业务 - ＆gt;数据
理想情况下交易应该从哪里开始？
有一种观点认为交易应该只从数据层的顶部开始。 Business层仅使用业务逻辑操作业务对象，并且从不了解事务。业务完成所有操作对象的工作，然后将它们交给数据层进行持久化。这是一种适用于较低层的RESTful哲学。
另一种想法是，交易应该从业务层的顶部开始。业务层定义了逻辑工作单元，而不是数据层，因为逻辑工作单元有时包含业务逻辑，而不仅仅是数据逻辑。
我确实喜欢尽可能降低交易问题。但我也发现，除非只是CRUD操作，否则可能需要额外的努力和设计挑战来尝试将业务逻辑保留在数据层之外。如果您使用大锤应用RESTful设计模式，则可以使应用程序具有非常少的非CRUD操作。
甚至还有第三种思想认为客户可以启动交易，以便在需要时可以组合多个业务操作。但现在客户正在定义工作单位？这不是一个商业问题吗？
第四种思想认为，我的客户可能只是可以参与XA交易的SOA组件，即使在客户之外也是如此！
我们的开发人员希望某些标准更具体，而不仅仅是“在任何您想要的地方开始交易”
有没有人对这个问题有任何意见或建议？
谢谢！
答案 0 :(得分：2)
交易是一种商业概念，应该在业务层内进行协调。
单独操作对象通常没什么好处，跨越多种类型对象之间的操作已经是一个事务。因此，第一种思想就是处理真正的基本案例。
当您的业务层处理交易时，启动交易的人员并不重要：客户或其他服务。只有在业务层知道它们时，才能支持长时间运行（分布式）事务。
答案 1 :(得分：1)
在
中客户 - ＆gt;业务 - ＆gt;数据
体系结构，在业务层上定义事务总是更好。我建议事务定义为业务服务要么启动新事务，要么参与现有事务（如果已经启动）。这样可以处理其他业务服务调用业务服务的情况。
如果业务层将多个数据层调用作为同一请求的一部分，则在数据层中具有事务边界将失败，如
client1-＆GT; business1 =＆gt; data1，business1 =＆gt; DATA2