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

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

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

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

接口隔離原則（Interface Segregation Principle，ISP）：模塊之間的依賴應該建立在盡可能小的接口上。這意味著一個模塊不應該依賴于其不需要使用的接口，而應該只依賴于其需要的最小接口集合。

依賴倒置原則（Dependence Inversion Principle，DIP）：高層模塊不應該依賴于低層模塊，它們應該依賴于抽象接口。通過依賴于抽象接口，而不是具體實現(xiàn)，可以降低模塊之間的耦合度，提高系統(tǒng)的靈活性和可維護性。

無環(huán)依賴原則（Acyclic Dependencies Principle，ADP）：為了避免循環(huán)依賴，不要讓兩個模塊之間形成環(huán)狀依賴關系。解除循環(huán)依賴的方法是遵循依賴倒置原則，依賴于抽象接口而不是具體實現(xiàn)。

組合/聚合復用原則（Composition/Aggregation Reuse Principle，CARP）：在擴展功能時，應優(yōu)先考慮使用組合而不是繼承。通過組合的方式，可以靈活地組合不同的功能模塊，而不會造成繼承鏈的復雜性和耦合度的增加。

高內(nèi)聚與低耦合（High Cohesion and Low Coupling，HCLC）：模塊內(nèi)部應該保持高內(nèi)聚，即模塊內(nèi)部的各個元素應該緊密相關，完成相同的功能。同時，模塊之間應該保持低耦合，減少彼此之間的依賴關系，從而提高系統(tǒng)的靈活性和可維護性。

慣例優(yōu)于配置（Convention over Configuration，COC）：為了提高開發(fā)效率，應盡量采用慣例而不是過多的配置。通過使用慣例，可以減少配置的復雜性，提高代碼的可讀性和可維護性。

命令查詢分離（Command Query Separation，CQS）：在定義接口方法時，應區(qū)分命令（寫操作）和查詢（讀操作），將它們分離開來。通過分離命令和查詢，可以提高代碼的清晰度和可維護性。

關注點分離（Separation of Concerns，SOC）：將復雜的問題分解為多個簡單的問題，并分別解決這些簡單的問題。通過關注點分離，可以降低系統(tǒng)的復雜度，提高代碼的可理解性和可維護性。

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

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

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

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

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

我個人不太喜歡常規(guī)意義上的 “設計模式”?；蛘哒f，我們對設計模式常規(guī)的打開方式是有問題的。理解每一個設計模式，都應該放到它想要解決的問題域來看。所以，我個人更喜歡的架構范式更多的是 “設計場景” 的總結?！霸O計場景” 和設計模式的區(qū)別在于它有自己清晰的問題域定義，是一個實實在在的通用子系統(tǒng)。

“開閉原則” 推崇模塊業(yè)務 “只讀” 的思想，是很好的架構治理哲學。它告訴我們，軟件是可以以 “搭積木” 的方式搭出來的。核心的一點是，我們?nèi)绾涡纬筛嗟?“積木”，即一個個業(yè)務只讀、接口穩(wěn)定、易于組合的模塊。