从更通用的层面：流程系统 来讨论这两种架构思路，流程系统包括以下特点：
- 包含多个执行节点顺序流转。
- 执行节点的触发条件可能有很多种，比如手动触发、条件触发等。
- 每个执行节点可能绑定一个或者多个附加操作，比如在某个操作后要发送邮件或其他方式进行通知。
- 绑定的操作也可能有顺序要求。
基础架构思路为每个节点完成后同步触发附加操作：
这是典型的强一致，好处是流程简单，缺点是体验差：1. 用户端的节点流转响应慢，且如果存在批量流转的场景(比如活动系统的批量导入产品)整体用户操作体验几乎无法忍受。 2. 如果某个附加操作执行失败，则当前节点状态流转也失败，附加操作和节点流转不应该耦合在一起，附加操作是系统行为，节点操作是用户行为，不应该由于系统行为异常导致用户行为丢失。
所以基于以上考虑，附加操作和节点流转解耦开是必须要做的，给附加操作做异步是一种基础的解耦思路：
上面的架构图就是典型的命令型异步，节点状态变更时发送一个异步命令做附加操作，命令里有具体的执行内容。
上面的架构对于附加操作有顺序要求的场景无法满足，因为都是异步操作，可能节点2的附加操作要先于节点1的附加操作，解决这个顺序问题的唯一方案只能给当前流程所有的附加操作顺序入队出队执行：
经过队列化以后系统正确性已经可以保证，但是从上面的架构图可以看出，面向用户端的节点状态变更承担了计算命令的工作，而计算命令某些场景下是个比较复杂的任务，比如对于条件流转的场景：
从上图看可能用户操作了节点1，而目标节点是节点3，中间需要发送节点1、节点2的所有附加操作，同样对于批量操作场景这个问题会被放大。这个问题也是命令型无法避免的缺陷。所以该系统设计的正确方向应该是状态流转尽量轻量化，后台可以承担更复杂的计算任务：
给用户端的操作尽量简化，给后端系统设计为自流转，这样用户操作后只需要修改状态并发送一条异步的状态变更消息即可。