转账问题是属于业务问题还是属于技术问题？

将钞票在两个账户之间转移属于业务问题还是技术问题？如果属于业务问题，就使用DDD等方式去解决，如果使用技术问题，就使用分布式事务组件或中间件或数据库去解决。

但是很多人默认这是一个技术问题，可以使用技术上的事务机制确保一个账户减去的钱等同于另外一个账户增加的钱。本文重点不是讨论谁对谁错，而是讨论大家忽视的边界划分问题，在你采购分布式事务时你有没有倒问自己，这种用技术解决问题的解决方案是不是违背一条裤子适合所有人穿的人月神话？

账户中金额转账无疑属于业务问题，但是在追求效率的今天，手工银行转账时代需要通过记账方式实现，而今有了大型数据库则成为非常快速瞬间的事情。但是且慢，非常快速是如何快速？是一秒之内还是一眨眼？一眨眼是多少秒？这个账户前一秒减去一万元，那个账户后一秒就增加一万元？这种实时一致性背后有什么机制？

CAP机制，两个账户金额变动的延迟越小，说明一致性越高，但是有时我们真的需要这种一秒或几毫秒之内的高实时一致性吗？这还会金额诈骗提供方便了呢！

所有这些考量都要取决于业务上下文，实际上现实中也不存在瞬间转账的场景需求。这会为洗钱监控带来不便。

因此，如果纯粹从技术角度通过分布式事务中间件或数据库来解决转账问题，就陷入技术至上的误区，这些技术至上的人会推崇分布式事务，而认为DDD等业务分析设计方式是屠龙宝刀，实际上相反，分布式事务才可能最是屠龙宝刀，神话一样存在，但是没有使用价值和场景。

当然，这里不想陷入算法技术和业务解决方案的无休止争论中，这是长期两种思维模型而已。

那么使用业务方法如何解决转账问题？这里也不详细讨论，主要从领域事件和事件溯源角度去考虑，也有使用区块链这种方式，为什么我说区块链会摧毁中心化的分布式事务组件技术？因为现有分布式事务机制无论如何分布，都是基于一个信任中心下的分布，不是真正基于不信任的分散，方向完全不同。

江山易改，思维难移，本文目的无非是如果你遭遇转账之类问题，首先业务战略高度去想想，而不是被神话技术忽悠主导。

相关：

分布式事务可能是个伪概念