開閉原則包含以下兩層含義：

模塊的業務穩定性是架構治理的核心理念之一。按照“只讀”設計原則，一旦模塊的業務穩定，就不應頻繁進行變更。相反，如果業務需要變化，更好的做法是將其歸檔或放棄，以保持系統穩定。這種“只讀”思想是架構治理的基石，強調每個模塊都應該是一個獨立可完成的單元。實際上，這也是對開閉原則在業務層面的另一種表述方式。

模塊業務的變化點應該以簡單或復雜的方式開放給其他業務模塊。對于簡單的變化點，可以通過回調函數或接口來實現，從而交給其他模塊處理。而對于更復雜的變化點，可以通過引入插件機制來將系統分解為“最小化的核心系統 + 多個彼此正交的周邊系統”。需要注意的是，回調函數或接口本質上就是一種事件監聽機制，因此可以視作插件機制的特例。這種方式可以有效地管理系統的變化點，提高系統的靈活性和可維護性。

實際上，我們以前也有設計原則，它們之中不乏精彩絕倫、振聾發聵的總結。比如：

接口隔離原則（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）：將復雜的問題分解為多個簡單的問題，并分別解決這些簡單的問題。通過關注點分離，可以降低系統的復雜度，提高代碼的可理解性和可維護性。

這些都是很好很好的。但是，我們需要意識到的一點是，熟讀架構思維并不足以讓我們成為優秀的架構師。

盡管架構思維對于軟件工程至關重要，但我們必須牢記，軟件工程的復雜性是自然存在的，它不會因為良好的架構思維而消失。因此，雖然理解架構思維至關重要，但真正的架構師武器庫并不局限于此。那么，架構師的真正武器庫是什么？答案是從架構治理開始談起。正如我們之前提到的，“開閉原則”倡導了模塊業務的“只讀”思想，這是一種優秀的架構治理哲學。它告訴我們，軟件可以像搭積木一樣構建。關鍵在于，我們如何形成更多的“積木”，也就是那些業務只讀、接口穩定、易于組合的模塊。因此，真正提高我們工程效率的是我們的業務分解能力和歷史積累的成果。

在架構分解過程中，存在兩大挑戰：第一是需求交織，即不同需求混雜在一起，形成了所謂的全局性功能。第二是需求易變，即不同客戶、不同場景下的需求看起來截然不同，并呈現出發散趨勢。這些挑戰需要我們認真應對，以確保軟件系統的靈活性和可維護性。

作為架構師，心性至關重要。架構師需要堅守對業務進行正交分解的信念，不斷探索各類需求的架構分解方法。這種思考過程漸漸形成了各種架構范式，它們不僅僅是一些架構思維，更是“一個個業務只讀、接口穩定、易于組合的模塊 + 組合的方法論”，構成了架構師真正的武器庫。

這個武器庫包含了許多內容。首先，它應該包括信息科技形成的基礎架構，將前輩們的經驗與自己的實踐相結合。但光是了解還不夠，更重要的是深刻理解基礎架構背后的架構邏輯，并確保將其完全融入自己的思維體系中，達到與基礎架構的“同頻共振”。只有這樣，當架構設計需要時，我們才能“想到它們”。有趣的是，有些人可能看似博學多才，但在實際的架構設計中卻很難將他們的知識運用起來。

我個人不太喜歡常規意義上的 “設計模式”。或者說，我們對設計模式常規的打開方式是有問題的。理解每一個設計模式，都應該放到它想要解決的問題域來看。所以，我個人更喜歡的架構范式更多的是 “設計場景” 的總結。“設計場景” 和設計模式的區別在于它有自己清晰的問題域定義，是一個實實在在的通用子系統。

“開閉原則” 推崇模塊業務 “只讀” 的思想，是很好的架構治理哲學。它告訴我們，軟件是可以以 “搭積木” 的方式搭出來的。核心的一點是，我們如何形成更多的 “積木”，即一個個業務只讀、接口穩定、易于組合的模塊。