如果给你一个明确的需求说明文档，干干净净地从头开始做 “需求分析”，做 “概要设计”，做模块的 “详细设计”，最后编码实现，这是理想场景。
现实中，大多数情况并不是这样。而是：你拿到了一份长长的源代码，加上少得可怜的几份过时的文档。然后被安排做一个新功能，或者改一个顽固缺陷（Bug）。
我们应该怎么做架构设计？
架构设计架构设计，设计为先，架构为魂。
用架构的系统化和全局性思维来做设计。
架构之道，是虚实结合之道。
我们要理论与实践相结合。架构设计不可能只需要熟读某些架构思维的理论，否则架构师早就满天飞了。
如果两者只能取其一，我选实践。从实悟虚，从虚就实，运用得当方得升华。这其实是最朴素的虚实结合的道理。对学架构这件事来说尤其如此。架构思维的感悟并不能一步到位，永远有进步的空间，需要我们在不断实践中感悟，升华自己的认知。
从技能来说，我们可能把架构师能力去归结为：理需求的能力；读代码的能力；抽象系统的能力。
但架构师的成长之旅，首先是心性修炼之旅,包括:同理心的修炼，认同他人的能力；全局观的修炼，保持好奇心和学习的韧性；迭代能力的修炼，学会反思，学会在自我否定中不断成长
业务的正交分解
架构就是业务的正交分解。每个模块都有它自己的业务。架构行为的三步曲：“需求分析”、“概要设计”、模块的 “详细设计”，背后都直指业务的正交分解，只是逐步递进，一步步从模糊到越来越强的确定性，直至最终形成业务设计的完整的、精确无歧义的解决方案。
怎么做业务分解？
业务分解就是最小化的核心系统，加上多个正交分解的周边系统。核心系统一定要最小化，要稳定。坚持不要往核心系统中增加新功能，这样你的业务架构就不可能有臭味。
所以业务做正交分解的第一件事情，就是要分出哪些是核心系统，哪些是周边子系统。核心系统构成了业务的最小功能集，而后通过不断增加新的周边功能，而演变成功能强大的复杂系统。
在架构分解过程中有两大难题。
其一，需求的交织，不同需求混杂在一起。这是因为存在我们说的全局性功能。其二，需求的易变。不同客户，不同场景下需求看起来很不一样，场景呈发散趋势。
但无论如何，我们需要坚持作为一名架构师的信仰：
任何功能都是可以正交分解的，即使我目前还没有找到方法，那也是因为我还没有透彻理解需求。
架构的功夫全在平常。
无论是在我们架构范式的不断完善上，还是应对架构老化的经验积累上，都是在日常工作过程中见功夫。
我们不能指望有一天架构水平会突飞猛进。架构能力提升全靠平常一点一滴地不断反思与打磨得来。
在应对架构老化这件事情上，不要轻率地选择进行全局性的重构。要把功夫花在平常，让重构在润物细无声中发生。
从难度来说，全局性的重构比一个全新业务的架构过程要难得多。重构，不只是一个架构的合理性问题。它包含了架构合理性的考量，因为我们需要知道未来在哪里，我们迭代方向在哪里。
但重构的挑战远不只是这些。这是一个集架构设计（未来架构应该是什么样的）、资源规划与调度（与新功能开发的优先级怎么排）、阶段规划（如何把大任务变小，降低内部的抵触情绪和项目风险）以及持久战所需的韧性与毅力的庞大工程。
【总结】
架构设计的执行路径
– 业务，业务，还是业务。更好的抽象、分解、管理业务的复杂度才是架构发展的原动力。需求分析，领域理解才是根，架构是为魂。
– 拆解业务场景为「通用的设计场景组合」，并不断完善通用场景下的架构范式。
– 任何架构范式都可以拆解为：最小化的核心系统 + 多个彼此正交的周边系统。
– 生命不止，正交不断，这是架构师的信仰
原文始发于微信公众号（二进制跳动）：架构思维篇：架构之道，是虚实结合之道道，从实悟虚，从虚就实
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167426.html
