开闭原则包含以下两层含义：
模块的业务稳定性是架构治理的核心理念之一。按照“只读”设计原则，一旦模块的业务稳定，就不应频繁进行变更。相反，如果业务需要变化，更好的做法是将其归档或放弃，以保持系统稳定。这种“只读”思想是架构治理的基石，强调每个模块都应该是一个独立可完成的单元。实际上，这也是对开闭原则在业务层面的另一种表述方式。
模块业务的变化点应该以简单或复杂的方式开放给其他业务模块。对于简单的变化点，可以通过回调函数或接口来实现，从而交给其他模块处理。而对于更复杂的变化点，可以通过引入插件机制来将系统分解为“最小化的核心系统 + 多个彼此正交的周边系统”。需要注意的是，回调函数或接口本质上就是一种事件监听机制，因此可以视作插件机制的特例。这种方式可以有效地管理系统的变化点，提高系统的灵活性和可维护性。
实际上，我们以前也有设计原则，它们之中不乏精彩绝伦、振聋发聩的总结。比如：
接口隔离原则（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）：将复杂的问题分解为多个简单的问题，并分别解决这些简单的问题。通过关注点分离，可以降低系统的复杂度，提高代码的可理解性和可维护性。
这些都是很好很好的。但是，我们需要意识到的一点是，熟读架构思维并不足以让我们成为优秀的架构师。
尽管架构思维对于软件工程至关重要，但我们必须牢记，软件工程的复杂性是自然存在的，它不会因为良好的架构思维而消失。因此，虽然理解架构思维至关重要，但真正的架构师武器库并不局限于此。那么，架构师的真正武器库是什么？答案是从架构治理开始谈起。正如我们之前提到的，“开闭原则”倡导了模块业务的“只读”思想，这是一种优秀的架构治理哲学。它告诉我们，软件可以像搭积木一样构建。关键在于，我们如何形成更多的“积木”，也就是那些业务只读、接口稳定、易于组合的模块。因此，真正提高我们工程效率的是我们的业务分解能力和历史积累的成果。
在架构分解过程中，存在两大挑战：第一是需求交织，即不同需求混杂在一起，形成了所谓的全局性功能。第二是需求易变，即不同客户、不同场景下的需求看起来截然不同，并呈现出发散趋势。这些挑战需要我们认真应对，以确保软件系统的灵活性和可维护性。
作为架构师，心性至关重要。架构师需要坚守对业务进行正交分解的信念，不断探索各类需求的架构分解方法。这种思考过程渐渐形成了各种架构范式，它们不仅仅是一些架构思维，更是“一个个业务只读、接口稳定、易于组合的模块 + 组合的方法论”，构成了架构师真正的武器库。
这个武器库包含了许多内容。首先，它应该包括信息科技形成的基础架构，将前辈们的经验与自己的实践相结合。但光是了解还不够，更重要的是深刻理解基础架构背后的架构逻辑，并确保将其完全融入自己的思维体系中，达到与基础架构的“同频共振”。只有这样，当架构设计需要时，我们才能“想到它们”。有趣的是，有些人可能看似博学多才，但在实际的架构设计中却很难将他们的知识运用起来。
我个人不太喜欢常规意义上的 “设计模式”。或者说，我们对设计模式常规的打开方式是有问题的。理解每一个设计模式，都应该放到它想要解决的问题域来看。所以，我个人更喜欢的架构范式更多的是 “设计场景” 的总结。“设计场景” 和设计模式的区别在于它有自己清晰的问题域定义，是一个实实在在的通用子系统。
“开闭原则” 推崇模块业务 “只读” 的思想，是很好的架构治理哲学。它告诉我们，软件是可以以 “搭积木” 的方式搭出来的。核心的一点是，我们如何形成更多的 “积木”，即一个个业务只读、接口稳定、易于组合的模块。
