因此，在付款处理中，您有付款交易的概念。当付款或消息来自各种内部和外部接口(interface)时，可能会在某些关系数据库的某些主要基本交易表中创建支付交易(至少为了这个问题)。然后，交易的某种状态会通过一系列编辑而发生变化，直到达到几个最终状态之一(已付款或未付款、批准或拒绝等)。
在处理数据库时，当然有数据库事务，我的问题是，在数据库事务中处理支付事务是否有任何经验规则？事务通常是聚合根到许多其他表，以获取有关参与该交易的客户、持卡人、商家或速度设置的信息。
我可以看到一条规则:“永远不要在数据库交易中处理多个支付交易”。但在执行批处理类型操作时，我也可以看到数据库事务是正确的，此时您必须考虑整批事务成功或失败，因此您可以选择回滚。
最佳答案
正常的设计模式是遵循以下规则:使用数据库事务将数据库从一种有效状态转换到另一种有效状态。
在支付交易的上下文中，这可能意味着添加交易是一个数据库交易。然后，事务的每个处理步骤(如验证、履行等)将是另一个数据库事务。
I could see a rule saying, "never process more than one payment transaction in a database transaction"
出于性能原因或架构原因，您可以将多个逻辑事务放入一个物理事务中。这不一定是问题。不过，您需要确保工作不会丢失，因为失败将中止整个批处理。
关于database - 支付交易与数据库交易，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34224787/