REST与DDD

多谢banq提供的这两篇关于转账的实现。

通过设计一个Transaction聚合根，然后利用在一个聚合根内同时产生如下两个事件的方式确实比较新颖。

public void Post(decimal amount, string fromAccount, string toAccount)
{
   this.Apply(new AccountDebited(amount, fromAccount));
   this.Apply(new AccountCredited(amount, toAccount));
}

但是AccountDebited, AccountCredited这两个事件后面是会被Source Account, Destination Account响应的。我认真看了作者的设计，他的思路是在业务层面实现类似2pc的方式。就是Transaction聚合根先通知两个账号准备转账(Prepare)，然后再收到这两个账号的Prepared事件后，再同时产生AccountDebited, AccountCredited事件，然后参与转账的这两个Account再最后做一次确认操作；

我的疑问是，这里有一些细节，作者没有交代清楚。
1. 比如Account的余额信息的扣除和增加是在哪一步做的呢？是在Prepare完成后就立即做还是在AccountDebited, AccountCredited事件产生后的confirm阶段做？
2.从作者的描述中，我猜测是在confirm阶段在做余额的变动，那要是这两个账号中任意一个扣钱或加钱失败了呢？作者貌似没有给出后续的不就措施，比如，需要考虑回滚吗？还是只是通过错误日志监控？等待后续人工排查？
3.作者的设计方式虽然做到了AccountDebited, AccountCredited这两个事件同时产生，且能做到在一个事务内原子的方式持久化事件；但是source account, destination account余额的真正变化我觉得并没有做到原子操作。那即便AccountDebited, AccountCredited这两个事件同时产生了，那意义又在哪呢？

我的个人理解，转账操作本质上最终是要改变两个账号的余额，既然我们引入了source account, destination account这两个独立的聚合根来参与转账。也就是说，转账这个场景必定涉及两个聚合根的修改。作者虽然引入第三个聚合根Transaction来尝试解决转入和转出的原子事务性，但我觉得貌似这样的设计只是停留在表象，因为这两个事件并不是直接导致source account, destination account余额修改的事件；我们业务上“希望”转账是一个原子操作，但实际上可能吗？毕竟涉及到两个账号聚合跟的状态修改。既然我们做不到原子事务性，那就是只能采用最终一致性，那最终一致性很重要的一方面就是要考察是否有可靠的回滚或补救机制，保证流程中某一步出现异常时能回滚或发送补救命令来将状态恢复到原始状态。

对了，再补充一点，如果余额的变化是在confirm的时候做的，那Prepared的时候account做了什么呢？难道是在Prepared时就做了预扣款或预加款，然后这笔数字的款项相当于已经扣除了，这样才能保证confirm的时候，扣款才一定够扣；

如果是这样，要要是prepared执行了，但是confirm一直未执行，那又该如何处理呢？呵呵

实际上问题很多的，只要细细去想的话。

REST的修改操作，为啥不能RPC呢？

根据您文章的说法，状态要在客户端计算好，然后发送到服务器，这样会不会导致业务逻辑散布在UI中。

我记得REST只规定了修改操作要使用：POST、PUT和DELETE。

牧场这个案例给人感觉好像状态要在客户端计算，实际上再看看转账这个案例，转账是A帐号扣除钱，B账户增加钱，这么复杂的逻辑肯定不是在客户端计算的，会造成逻辑不一致性：
1.查询帐号A余额状态是10元
2.发出请求帐号A余额状态是5元(扣除5元，剩余5元)
3.查询帐号B余额状态是20元
4.发出请求帐号B余额状态是25元(增加5元)

这种方式就是逻辑在客户端计算，是不行的，被否决了。
应该是POST一个Transaction转账。Transaction转账在REST中是一个资源，而在DDD中是一个聚合根Aggregate root。

理解REST有两种角度，先有资源，然后是POST/PUT/GET/DELETE这些动作；还是先有这四个动作，才有资源。正如面向对象和面向函数的区别一样，第一考虑是先有类，才有类的方法函数，还是第一考虑先有函数，才有被函数操作的数据类。

这两种思维将程序员划分为两种世界。

其实编程经验也会将程序员划分为这两种世界。

有过Linux或一些纯平台开发经验的人，往往倾向于面向函数，因为这类应用几乎没有强烈的业务规则约束，数据就代表业务，包括大数据Big data等等。

面向函数的视角打个比喻：
如同一套机械加工设备，输入的是碎散草料，输出的是打包好成捆的草料。

好处就不多说了，无副作用，单纯职责等等。但是这里有一个前提，那就是输入的碎散草料是可以被投入到机械设备入口，如果投入的原料是一种有强烈内聚规则的业务模型，比如转账，转账有很强的内聚规则，那就是A帐号转出的必须等于B帐号转入的，否则就不叫转账。

如果将这样一个转账作为原料投入机械加工设备，机械是无法打散解构的，如同投入一个大石头，或者是金刚石，机械加工几乎无法完成自身的函数功能：打散扎捆。如同人吃进去石头，拉出来也只能石头，无法消化分解一样，函数和数据在这里是棋逢对手。

所以，在需求分析这块，数据代表领域模型，代表有一定业务约束的内聚模型，应当以数据结构为主要，函数是次要；而在大数据分析这块，因为数据本来就是松散碎的，无结构化，那么我们通过Hadoop之类加工机械找出数据自己的某种关系，结构的或其他方面的。

prepared并不是真正扣款，而是坚持余额是否能够被扣款，如果余额只有5元，要转账出去10元，那就没有prepared，下一步就不会进行；如果准备好了，表示余额足够，而且B帐号也准备好能够被转入，不存在冻结等情况，再进行转出和转入，但confirm事件发生时，转出和转入已经发生。

我把原英文的过程大意翻译如下：
首先，聚合根Transaction转账这个实体发出prepared这个事件，实际是检查是否准备好的事件，如下图

prepared这个事件发往A和B两个账户，变成它们的命令command。图中黄色部分代表命令，从两个账户出来变成蓝色的事件了。

两个帐号检查自己余额等条件，认为具备转账条件，上图发出的蓝色事件，表示准备好了，变成向聚合根转账实体发出的命令，如下图的黄色：

同理，上图聚合根发出总攻命令，进行真正转账，余额扣除和增加，变成下图的黄色命令，下图两个账户在余额变动后，发出确认完成的事件，如下图蓝色部分，这两个事件发回聚合根实体转账，转账回复REST客户端200 OK。

DCI+面向函数风格：
有点像统治阶级管理它国土上的各种资源，啥都是它说了算，结果啥事情它都得考虑，它都得做。各种判断、各种操作都集中在一起了，形成了一个大函数。
当统治阶级要换了（技术更新），整个国家就跨了，代码基本无法重用，或需要费大力气重新组织。
效率来说，命令式应该会高点，毕竟一个人说了算嘛。稳定性就不那么行了。

DDD聚合体+EventSourcing方式：
有点像自由联邦，各种资源分散到各个联邦中自己管理，大家遵守一套共同的规范和道德准则。它们之间没有命令，只有请求（回想现实世界，说到底，哪个事情不是请求别人做呢，还真能命令别人一定这么做？）。
当国家变革了，可以保证各个联邦内部的稳定。即使变革不可逆转，也可一个个联邦慢慢来进行，不会一次崩溃。
效率感觉会低点，但国家会比较稳定。

自己的一些胡思乱想（对DCI 、DDD、Rest 不太了解）

不错，听这些故事，感觉对这些技术名词有感性多了，谢谢Banq

我就想问如果我部署了分布式，有多个Actor在同一时刻同时通过分布式的消息，再经过分布式的数据库让Transfer同时执行到了prepared方法时，是不是失效了？

可使用Eventuate:基于操作CRDT的服务框架实现分布式EventSourcing最终一致性。