有同学提到工程思维，认为借助传统的建筑、机械工程的思考方式，有助于控制软件工程质量¹。这当然是有益的。

我们意识到系统中存在的大量结构性问题，根源都是我们知识的结构问题。 在知识结构层面，我们有两个主要问题。

随着系统和团队规模逐渐成长，开发质量问题¹一般有增多趋势。

最近，网红架构师学镛老师提出了观点，说用对象模型来体现领域已不太适用于现代系统环境，比如分布式和高并发。¹

当系统成长的时候，大家都想到“微服务”。

度过初创期，业务复杂性明显发展，系统结构和质量越来越受到重视。

需要考虑如何管理领域¹。

性能、可用性、可伸缩、可扩展……如何达成这些质量要求，是随时要考虑的问题。 有没有什么“普遍的”考虑方法呢？

宣言的其他方面描述的都是系统的外部特征：快速响应、容错、压力下的弹性。为什么单单加入“消息驱动”这个实现策略呢？

那么，微服务应该强调什么微呢？

微服务的微，是指服务粒度的微么？