architecture - 您如何在 Clean Architecture 中使用事务？

Question

我在网上找不到它的任何实现实际上为您提供了一种与框架无关且实用的实现方式。

我已经看到了几个解决它的低于标准的建议:

使存储库方法成为原子

使用例原子化

它们都不是理想的。

案例#1 :大多数用例依赖于多个存储库方法来完成他们的工作。当您“下订单”时，您可能需要调用“订单存储库”的“插入”方法和“用户存储库”的“更新”方法(例如:扣除商店信用)。如果“插入”和“更新”是原子的，这将是灾难性的——您可以下订单，但实际上无法让用户为此付费。或者让用户为此付费，但订单失败。两者都不理想。

案例#2 : 没有更好的。如果每个用例都存在于一个孤岛中，它就会起作用，但是除非您想复制代码，否则您经常会发现自己拥有依赖于其他用例操作的用例。

想象一下，您有一个“下订单”用例和一个“提供奖励积分”用例。两个用例都可以独立使用。例如，当系统推出周年纪念日期间登录时，老板可能希望向系统中的每个用户“给予奖励积分”。并且您当然会在用户进行购买时使用“下订单”用例。

现在，您的系统发布 10 周年了。你的老板决定 - “好吧 Jimbo - 2018 年 7 月，只要有人下订单，我就想给奖励积分”。

为避免为这个可能会在明年放弃的一次性想法直接改变“下订单”用例，您决定创建另一个用例(“在促销期间下订单”)，它只是调用“下订单”和“给予奖励积分”。精彩的。

只是……你不能。我的意思是，你可以。但你又回到了原点。您可以保证“下订单”是否成功，因为它是原子的。并且您可以保证“给予奖励积分”是否因同样的原因成功。但是，如果其中任何一个失败，您就无法扮演另一个角色。它们不共享相同的事务上下文(因为它们在内部“开始”和“提交”/“回滚”事务)。

上面的场景有几种可能的解决方案，但它们都不是很“干净”(想到了工作单元——在用例之间共享一个工作单元可以解决这个问题，但 UoW 是一个丑陋的模式，而且仍然存在知道哪个用例负责打开/提交/回滚事务的问题)。

Answer 1

我把交易放在 Controller 上。 Controller 知道更大的框架，因为它可能至少有像框架注释这样的元数据。

至于工作单位，这是一个好主意。您可以让每个用例启动一个事务。在内部，工作单元要么启动实际事务，要么增加调用启动的计数器。然后每个用例都会调用 commit 或 reject。当提交计数等于 0 时，调用实际提交。拒绝跳过所有这些，回滚，然后出错(异常或返回代码)。

在您的示例中，包装用例调用 start (c=1)，下单调用 start(c=2)，下单提交 (c=1)，奖金调用开始 (c=2)，奖金调用提交 (c= 1), 包装提交 (c=0) 所以实际提交。

我把子事务留给你。