67 | 架构思维篇：回顾与总结

周边功能对核心系统总伤害的经验公式的本质，我总结为，不论自己设计的架构静态看起来有多么完美，各模块之间的配合有多么精妙，如果从外部给它施加一个扰动（比如需要修改某个模块），会导致整体发生剧烈的变化，那么这个架构就不是好的架构。 就像机械系统，一定要考虑公差。系统要与误差共舞，要能抵抗变化，必须处于一个动态的平衡点。

aha moment，大道总是至简的：虚实结合、全局思维/正交细节。 按照个人的理解，复述下架构设计的执行路径(top-down)： - 业务，业务，还是业务。更好的抽象、分解、管理业务的复杂度才是架构发展的原动力。需求分析，领域理解才是根，架构是为魂。 - 拆解业务场景为「通用的设计场景组合」，并不断完善通用场景下的架构范式。 - 任何架构范式都可以拆解为：最小化的核心系统 + 多个彼此正交的周边系统。 - 生命不止，正交不断，这是架构师的信仰。 谢谢老师。

老师从开闭原则 对aPaaS 这个概念怎么看呢。烦请指教

没重构过就看不懂架构课，就像不实践就没法真正理解一个道理一样。边学边实践才能真正理解老师所讲的内容，而且真的是一步一步理解的。

看了一些架构书籍，但一直觉得无法入门。直到今年大量重构项目后，才感觉有点打开这扇门了。面向对象思想，设计原则，领域建模，代码规范，重构手法这些亦是架构之道。 对于重构，我遵循的是<重构 第二版>的小步快跑的模式，在每次需求迭代顺带重构周边业务。我追求的是用最小的成本（改动少，验证范围收敛）解决最大的问题（可读，可扩，性能及更明确的语意），是四两拨千斤的效果而非千斤拨千斤的蛮力。解决问题是目的，优雅的解决问题才是追求。 栏主后面的篇幅没有第一章指点江山的气势。但落笔都很精准，要么引发反思要么引起共鸣，依旧受益匪浅。马上最后一章了，真舍不得完结。

在应对架构老化这件事情上，不要轻率地选择进行全局性的重构。要把功夫花在平常，让重构在润物细无声中发生。 拿小本本记下来

架构设计要满足现有功能，还要能适应未来的业务变化，这点通常是最难的，要预测未来。同时许老师也强调了一点，业务模块的正交分解，架构设计的开闭原则，让业务具备了良好的隔离性和可扩展性，也让未来的修改更容易些。

一门学科的历史，就是这门学科的本身。从老师的信息科技的演进历史收获很多，期待 数据治理与业务运营体系构建 这本书早日出来

读到目前，能感受到老师对于架构的理解和体悟之深，但文字表达的能力真的有限。很多核心的观点只能用不断重复来加重点表述。

听老师的课，有一种行云流水的感觉，非常舒服。