查看原文

这篇文章中作者不建议写 Entity Service (指的是那种提供数据增删改查的服务），想对比数据，更应该从用户行为开始着手设计系统。

作者介绍了一种构建系统的简易方法："Tell, Don't Ask."。它其实源于我们在大学里面学到的经典软件开发流程：整理 Use Case，抽象领域模型，然后构建系统。具体操作方法是这样：假设你扮演一个你要实现的系统，要处理一个用户请求。系统中的每个服务不向外问信息，只给请求增加信息，然后传递给下一个系统。

它生成的系统设计，会使将一套行为封装进服务中，服务对外发布仅能自己这个服务给出的消息，其它服务或订阅消息或被主动触发。事实上，这些消息最合适被推到的地方，就是 a message bus。

一致性问题仍然会出现，解决方法作者下期给出来。

衍生思考：

• 我觉得接触过 Redux 的前端同学都会笑而不语，后端们怎么在纠结这么简单的问题。你们的 Message Bus 就是 Redux 里面的 Store，这个消息就是 Redux 里面的 Action。
• 一致性问题怎么解？我猜可以在消息里面带一些可以做一致性检查的信息，服务对无法通过一致性检查的信息拒绝请求。另外，忽略一些不严重的场景，用些脚本做事后修复。关于这个场景，我觉得参考支付网关类的应用最为合适，例如 Stripe。但还是等到下次看作者的解法。
• 我并不觉得两种系统有优劣之分，还是得看场景和个人偏好。甚至，两种风格混用问题也是不大的。