假设在一个应用中，客户注册了一个新账号，而这个动作会触发以下逻辑：
- 在客户的积分账户中创建一条积分记录；
- 通过邮政系统派送一个欢迎礼包；
- 向客户发送欢迎电子邮件；
创建新账号的流程图为：
考虑具体实现时 , 有两种架构可以选择 。
1 编排 (orchestration)
编排架构，会有某个中心大脑来领导并驱动整个流程 , 这个大脑就像交响乐队中的指挥。
编排架构的缺点是 , 客户服务作为中心控制点承担了太多职责 , 它会成为网状结构的中心枢纽及很多逻辑的起点 。 这种架构可能会导致出现 “老大哥 ” 服务 , 而与其打交道的其它服务会沦为仅是基于 CRUD 的 “贫血” 服务。
2 协同 (choreography)
协同架构，会预先说明清楚系统中各个部分各自的职责 , 而把具体怎么实现留给各个部分它们自己 。
在刚才的示例中，我们可以使用异步的方式从客户服务中触发一个名为“ 客户创建 ”的事件 。 积分服务、包裹服务以及邮件服务订阅这个事件 。 这种架构的好处是能够显著地消除耦合 。
这种架构的缺点是 , 不能直观地看出整体业务流程 。因此，我们必须监控整套流程 , 以确保其能正确地流转 。这需要构建一套与上图业务流程相匹配的监控系统。
总的来说，协同架构不仅可以降低系统的耦合度 , 还可以让我们以更加灵活的方式修改现有系统。
应该根据具体的实际技术，来选择最适宜的架构。
