64 | 不断完善的架构范式
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
总结来说，开闭原则包含以下两层含义：
第一，模块的业务要稳定。模块的业务遵循 “只读” 设计，如果需要变化不如把它归档，放弃掉。这种模块业务只读的思想，是架构治理的基础哲学。我平常和小伙伴们探讨模块边界的时候，经常会说这样一句话：
每一个模块都应该是可完成的。
这实际上是开闭原则的业务范畴 “只读” 的架构治理思想的另一种表述方式。
第二，模块业务的变化点，简单一点的，通过回调函数或者接口开放出去，交给其他的业务模块。复杂一点的，通过引入插件机制把系统分解为 “最小化的核心系统 + 多个彼此正交的周边系统”。事实上回调函数或者接口本质上就是一种事件监听机制，所以它是插件机制的特例。
上一讲我们介绍了接口设计。到此为止，我们的架构思维篇也已经基本接近尾声。可能有人会越来越奇怪，为什么我还是没有去聊那些大家耳熟能详的架构设计原则？
实际上，并不是这些架构设计原则不好，它们之中不乏精彩绝伦、振聋发聩的总结。比如：
接口隔离原则（Interface Segregation Principle，ISP）：一个模块与另一个模块之间的依赖性，应该依赖于尽可能小的接口。
依赖倒置原则（Dependence Inversion Principle，DIP）：高层模块不应该依赖于低层模块，它们应该依赖于抽象接口。
无环依赖原则（Acyclic Dependencies Principle，ADP）：不要让两个模块之间出现循环依赖。怎么解除循环依赖？见上一条。
组合 / 聚合复用原则（Composition/Aggregation Reuse Principle，CARP）：当要扩展功能时，优先考虑使用组合，而不是继承。
高内聚与低耦合（High Cohesion and Low Coupling，HCLC）：模块内部需要做到内聚度高，模块之间需要做到耦合度低。这是判断一个模块是在做一个业务还是多个业务的依据。如果是在做同一个业务，那么它所有的代码都是内聚的，相互有较强的依赖。
惯例优于配置（Convention over Configuration，COC）：灵活性会增加复杂性，所以除非这个灵活性是必须的，否则应尽量让惯例来减少配置，这样才能提高开发效率。如有可能，尽量做到 “零配置”。
命令查询分离（Command Query Separation，CQS）：读写操作要分离。在定义接口方法时，要区分哪些是命令（写操作），哪些是查询（读操作），要将它们分离，而不要揉到一起。
关注点分离（Separation of Concerns，SOC）：将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。当然这条说了等于没说，难在如何进行分离，最终还是归结到对业务的理解上。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
架构师的武器库不仅包括架构思维，更重要的是对基础架构的深刻理解和业务架构的设计能力。开闭原则是架构治理的基础哲学，强调模块业务的稳定性和易于组合的特性。架构师需要坚持对业务进行正交分解的信念，不断探索各类需求的架构分解方法，形成各种架构范式。理解基础架构和行业领域知识，加上业务架构设计能力，是设计优秀业务系统的关键。此外，数据相关的体系也是架构师需要关注的重要内容。 文章强调了架构师需要具备深刻的基础架构理解和业务架构设计能力，以及对开闭原则的理解和应用。作者提出了“设计场景”作为架构师的真正武器库，强调架构师需要具备极强的架构范式的抽象能力。此外，文章还提到了下一讲的话题是“架构范式：文本处理”。 总的来说，本文强调了架构师需要具备的技术能力和思维模式，以及对架构范式的重视。文章内容深入浅出，对架构师的要求和技术特点进行了详细阐述，对于想要了解架构师职业要求和技术发展方向的读者具有很高的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(17)
- 最新
- 精选
Eternal“开闭原则” 推崇模块业务 “只读” 的思想，是很好的架构治理哲学。它告诉我们，软件是可以以 “搭积木” 的方式搭出来的。核心的一点是，我们如何形成更多的 “积木”，即一个个业务只读、接口稳定、易于组合的模块。这个比喻比前面的介绍更加通俗易懂作者回复: 嗯，搭积木是大家常听到的比喻。但是只有结合 “只读” 设计才是完整的开闭原则。
2020-02-015
靠人品去赢什么时候也能自己负责一个产品的架构，从业务上考虑但是呢还能在开闭原则上有考虑，不至于业务方向一变就要开始打补丁。作者回复: 加油
2019-12-134
leslie许老师的课一路跟随至今除了桌面开发平台这块确实有些前端，没有去扩展；其它的基础架构不少是这些年工作中经历过然后觉得自己太浅或深度不够都进行了扩展，然后不知不觉中发现自己每个月都处在高压学习和自我总结中；年末看自己的学习课程发现突然比预计多了差不多10门，辛苦却收益满满。 关于老师提及的两块提出一些个人的学后感: 一块是业务:老师课程中"业务只能靠你自己的架构设计能力去构建它。"个人觉得是产品的思路刚好对应了业务角度；后期又在此进行了扩展，然后发现确实理解的更加深了。 一块是数据:在"键值存储和数据库“提及了"中间件存储"的概念其实就是"其实就是站在数据系统的角度去思考的，当时学习就一堆反思以及进一步的把市场上数据相关的经典书籍，在某本书籍中看到了"数据系统"这个词，其实这就是数据架构层对此的解释；然后再结合《深入浅出计算机组成原理》把那两章老师的课程又学了一遍；架构同样是层层嵌套，每块都要结合软硬件层架构去思考才能理解。 关于老师所说的“数据治理与业务运营体系构建”，个人觉得同样是基于中间件存储和数据系统去从业务层进一步去讲解；这其实就体现了老师课程中提及的"架构师需要有自己的信仰。我们需要坚持对业务进行正交分解的信念，要坚持不断地探索各类需求的架构分解方法。这样的思考多了，我们就逐步形成了各种各样的架构范式。"。 谢谢老师辛勤的付出，虽然跟随学习的过程确实辛苦，不过收获的喜悦这其实就是IT从业者真正追求的。非常期待老师《数据治理与业务运营体系构建》课程的推出：感谢老师的分享，期待下堂课继续跟随老师学习，跟随老师进步。作者回复: 有付出必有回报
2019-12-132- Sam跟着许大这一路走来，让我在架构认知上得到前所未有的提高，更是不断的遵循“架构是门实践”的学课原则，不断的在工作中实践。眼看课程就要结束了，真担心在课程结束后遇到无法解决的架构难题时找不到方向，希望课程结束后还能以某种方式与老师保持联系和沟通。2019-12-1315
歌在云端买了这么多课程，感觉还是许老师的讲的最好，最有深度2019-12-138
黄强把虚的事情往实里做，才有可能真正做好。 市面很多PPT架构师是将实的事情往虚离做，^_^2020-04-063
有米通用的设计场景，我理解是，比如秒杀、热点账户、缓存雪崩、重复支付等等这些场景，都有通用的解决方案，我们将一个很大的系统拆解出来后，就会出现类似的种种问题，但我们总能随心所欲的挑出最合适的方案去解决它们。也就是用合适的“积木”去搭出一座满足需求的大厦。2020-04-043
知行合一有深度，我理解不是很到位，感觉自己还得再从头刷一遍2019-12-182
轶名有种拨开云雾见月明的感觉2019-12-131
ifelse
学习打卡2023-10-07归属地：浙江
收起评论
