系统的上线就意味着给业务带上了手铐。（已经忘了是从哪听来的这句话了）
变是永远不变的现实情况，因为变是源自于认知的升级。
变有哪几种类型呢？假设以纯人工方式进行一项业务：
- 个体变了（单个职责 [ 功能 ] 变了，不影响他人）
- 流程变了（分工界面 [ 接口 ] 变了，会影响他人）
- 流量变了（功能分工都没变，就是要多安排人手 [ 水平扩容 ] ）
一般来说，一个信息系统的交付，一定是以整体需求为基础，按照瀑布或敏捷方式进行交付的。
在这个交付过程中，工程师们在落地形态上，会把一些「功能」和「接口」在物理形态上进行集成。
这样高聚合的实现设计，一方面是由于过往硬件成本过高，另一方面也是由于担心跨进程所引起的不必要性能开销。
高聚合的设计，为将来系统进行业务进化，种下了许多「技术债务」的种子。
技术债务中的很大一部分，来自于后人对「业务逻辑」的不理解，没有文档，晦涩难懂的接口名称，一团乱麻的逻辑......
在微服务落地的过程中，当系统落地方，接手一个完整的、冗长的业务需求说明，就意味着99%的场景下，微服务不太可能实现，因为很有可能看不见拆分的原则。
也许有一种视角，就是能够知道一个企业中的全部业务流程，并对业务流程进行优化和缩短，也许这种方式是业务和技术都愿意看到的情况。
一个微服务 ( Actor ) 应该是一个职能在虚拟世界中的投影，一组微服务构成的能力域 ( Domain ) 就应该是一个部门在虚拟世界中的投影。
一个职能对应于一个微服务 ( Actor ) ，是合理的。
微服务有多少种不同结构上的拓扑形态，应该是取决于自然社会的业务形态。
