如果一个好主意50年了还没有落地，那它也不是那么好的主意

Self-Contained Systems 描述了一种“自包含架构”的愿景。通俗的说，就是要竖切，不要横切。

这个想法至少可以追溯到 David Parnas 《On the Criteria To Be Used in Decomposing Systems into Modules》。作者在文中写道

We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.

这篇文章写于 1971 年，50年过去了，仍然普遍不落地。我想说

如果一个好主意50年了还没有落地，那它也不是那么好的注意

大致想想，就可以列出如下无法落地的理由：

• 怎么说服你的同事，靠每个人送一本书吗？
• 怎么判断什么横，什么是竖，都靠你的一张嘴吗？
• 当过几天发现切错了，如何调整？切都切开了，谁愿意放弃自己手里的“影响力”？
• 听起来是要前后端数据库同时变更升级啊，这样风险多高啊。切成微服务，可以控制变更风险。
• 想同时升级也不可能啊。端是 iOS 的，要把整个端的代码集成到一起提交给苹果审核，也没法强制用户升级。一个版本发出去了，就得 API 兼容一辈子噢。
• 不要想着让我做“业务的人”，我就是“java的人”，“k8s的人”。谁也不会给你打一辈子的工，我有我自己的职业赛道，我要为下一份工作面试做好准备
• 端都是深度集成的，一个界面上要展示各个竖块的信息，而且是混一起的。一个按钮要触发一堆操作，而且是有前后逻辑依赖的。产品经理要求c端的都在一起，b端都在一起，骑手端的东西都在一起，客服工作台的东西都在一起。

当我们提出反对拆分微服务的时候，你要比拆微服务提出更彻底的拆分方案，否则只是重复念单体就够了，别人还是会去走向微服务。

当我们提出要抽象，要归纳出规范的时候，一定要先把特殊性给隔离出去。剔除了没规律的，剩下的就是有规律的了。剔不出去没规律的，强行归纳只会适得其反。

当我们提出要隔离关注点，要单一职责，那就得先回答好拆完了之后怎么集成回去。一味强调要拆出来，没有集成回去完成需求的能力，为了避免拆完了需求实现不了，那啥也拆不出来。

如果不能遗忘，也不会真正的记住。

也就是，合的基础是分。规范的基础是特殊。隔离的基础是集成。如果一个好主意50年了还没有落地，那一定是有原因的。