如果给你一个明确的需求说明文档，干干净净地从头开始做 “需求分析”，做 “概要设计”，做模块的 “详细设计”，最后编码实现，这是理想场景。

现实中，大多数情况并不是这样。而是：你拿到了一份长长的源代码，加上少得可怜的几份过时的文档。然后被安排做一个新功能，或者改一个顽固缺陷（Bug）。

我们应该怎么做架构设计？

架构设计架构设计，设计为先，架构为魂。

用架构的系统化和全局性思维来做设计。

架构之道，是虚实结合之道。

我们要理论与实践相结合。架构设计不可能只需要熟读某些架构思维的理论，否则架构师早就满天飞了。

如果两者只能取其一，我选实践。从实悟虚，从虚就实，运用得当方得升华。这其实是最朴素的虚实结合的道理。对学架构这件事来说尤其如此。架构思维的感悟并不能一步到位，永远有进步的空间，需要我们在不断实践中感悟，升华自己的认知。

从技能来说，我们可能把架构师能力去归结为：理需求的能力；读代码的能力；抽象系统的能力。

但架构师的成长之旅，首先是心性修炼之旅,包括:同理心的修炼，认同他人的能力；全局观的修炼，保持好奇心和学习的韧性；迭代能力的修炼，学会反思，学会在自我否定中不断成长

业务的正交分解

架构就是业务的正交分解。每个模块都有它自己的业务。

架构行为的三步曲：“需求分析”、“概要设计”、模块的 “详细设计”，背后都直指业务的正交分解，只是逐步递进，一步步从模糊到越来越强的确定性，直至最终形成业务设计的完整的、精确无歧义的解决方案。

怎么做业务分解？

业务分解就是最小化的核心系统，加上多个正交分解的周边系统。核心系统一定要最小化，要稳定。坚持不要往核心系统中增加新功能，这样你的业务架构就不可能有臭味。

所以业务做正交分解的第一件事情，就是要分出哪些是核心系统，哪些是周边子系统。核心系统构成了业务的最小功能集，而后通过不断增加新的周边功能，而演变成功能强大的复杂系统。

在架构分解过程中有两大难题。

其一，需求的交织，不同需求混杂在一起。这是因为存在我们说的全局性功能。其二，需求的易变。不同客户，不同场景下需求看起来很不一样，场景呈发散趋势。

但无论如何，我们需要坚持作为一名架构师的信仰：

任何功能都是可以正交分解的，即使我目前还没有找到方法，那也是因为我还没有透彻理解需求。

架构的功夫全在平常。

在我们架构范式的不断完善和应对架构老化的经验积累方面，都需要在日常工作中逐步积累。我们不能指望架构水平会在一夜之间有质的飞跃，而是通过平时不断的反思和打磨来提升架构能力。

在应对架构老化时，不要轻率地选择进行全局性的重构。重构工作应该融入日常工作，通过平稳的改进过程让架构在不引起过多干扰的情况下逐渐改善。

从难度来看，全局性的重构要比创建全新业务的架构复杂得多。重构不仅仅是一个关于架构合理性的问题，还涉及到对未来方向的了解，以及在整个过程中如何引导团队的合作。这需要考虑架构设计、资源规划、阶段规划以及在持久战中保持韧性和毅力等多方面的因素。

【总结】

架构设计的执行路径

- 业务，业务，还是业务。更好的抽象、分解、管理业务的复杂度才是架构发展的原动力。需求分析，领域理解才是根，架构是为魂。

- 拆解业务场景为「通用的设计场景组合」，并不断完善通用场景下的架构范式。

- 任何架构范式都可以拆解为：最小化的核心系统 + 多个彼此正交的周边系统。

- 生命不止，正交不断，这是架构师的信仰