API與SPI分離
框架或元件通常有兩類客戶，一個是使用者，一個是擴充套件者， API(Application Programming Interface)是給使用者用的， 而SPI(Service Provide Interface)是給擴充套件者用的， 在設計時，儘量把它們隔離開，而不要混在一起， 也就是說，使用者是看不到擴充套件者寫的實現的， 比如：一個Web框架，它有一個API介面叫Action， 裡面有個execute()方法，是給使用者用來寫業務邏輯的， 然後，Web框架有一個SPI介面給擴充套件者控制輸出方式， 比如用velocity模板輸出還是用json輸出等， 如果這個Web框架使用一個都繼承Action的VelocityAction和一個JsonAction做為擴充套件方式， 要用velocity模板輸出的就繼承VelocityAction，要用json輸出的就繼承JsonAction， 這就是API和SPI沒有分離的反面例子，SPI介面混在了API介面中， 合理的方式是，有一個單獨的Renderer介面，有VelocityRenderer和JsonRenderer實現， Web框架將Action的輸出轉交給Renderer介面做渲染輸出。
服務域/實體域/會話域分離
任何框架或元件，總會有核心領域模型，比如： Spring的Bean，Struts的Action，Dubbo的Service，Napoli的Queue等等 這個核心領域模型及其組成部分稱為實體域，它代表著我們要操作的目標本身， 實體域通常是執行緒安全的，不管是通過不變類，同步狀態，或複製的方式， 服務域也就是行為域，它是元件的功能集，同時也負責實體域和會話域的生命週期管理， 比如Spring的ApplicationContext，Dubbo的ServiceManager等， 服務域的物件通常會比較重， 而且是執行緒安全的，並以單一例項服務於所有呼叫， 什麼是會話？就是一次互動過程， 會話中重要的概念是上下文，什麼是上下文？ 比如我們說：“老地方見”，這裡的“老地方”就是上下文資訊， 為什麼說“老地方”對方會知道，因為我們前面定義了“老地方”的具體內容， 所以說，上下文通常持有互動過程中的狀態變數等， 會話物件通常較輕，每次請求都重新建立例項，請求結束後銷燬。 簡而言之： 把元資訊交由實體域持有， 把一次請求中的臨時狀態由會話域持有， 由服務域貫穿整個過程。
在重要的過程上設定攔截介面
如果你要寫個遠端呼叫框架，那遠端呼叫的過程應該有一個統一的攔截介面， 如果你要寫一個ORM框架，那至少SQL的執行過程，Mapping過程要有攔截介面， 如果你要寫一個Web框架，那請求的執行過程應該要有攔截介面， 等等， 沒有哪個公用的框架可以Cover住所有需求，允許外接行為，是框架的基本擴充套件方式， 這樣， 如果有人想在遠端呼叫前，驗證下令牌，驗證下黑白名單，統計下日誌， 如果有人想在SQL執行前加下分頁包裝，做下資料許可權控制，統計下SQL執行時間， 如果有人想在請求執行前檢查下角色，包裝下輸入輸出流，統計下請求量， 等等， 就可以自行完成，而不用侵入框架內部， 攔截介面，通常是把過程本身用一個物件封裝起來，傳給攔截器鏈， 比如：遠端呼叫主過程為invoke()，那攔截器介面通常為invoke(Invocation)， Invocation物件封裝了本來要執行過程的上下文，並且Invocation裡有一個invoke()方法， 由攔截器決定什麼時候執行，同時，Invocation也代表攔截器行為本身， 這樣上一攔截器的Invocation其實是包裝的下一攔截器的過程， 直到最後一個攔截器的Invocation是包裝的最終的invoke()過程， 同理，SQL主過程為execute()，那攔截器介面通常為execute(Execution)，原理一樣， 當然，實現方式可以任意，上面只是舉例。
重要的狀態的變更傳送事件並留出監聽介面
這裡先要講一個事件和上面攔截器的區別，攔截器是干預過程的，它是過程的一部分， 是基於過程行為的， 而事件是基於狀態資料的，任何行為改變的相同狀態，對事件應該是一致的， 事件通常是事後通知，是一個Callback介面，方法名通常是過去式的，比如onChanged()， 比如遠端呼叫框架，當網路斷開或連上應該發出一個事件，當出現錯誤也可以考慮發出一個事件， 這樣外圍應用就有可能觀察到框架內部的變化，做相應適應。
擴充套件介面職責儘可能單一，具有可組合性
比如，遠端呼叫框架它的協議是可以替換的， 如果只提供一個總的擴充套件介面， 當然可以做到切換協議， 但協議支援是可以細分為底層通訊，序列化，動態代理方式等等， 如果將介面拆細，正交分解，會更便於擴充套件者複用已有邏輯，而只是替換某部分實現策略， 當然這個分解的粒度需要把握好。
微核外掛式，平等對待第三方
大凡發展的比較好的框架，都遵守微核的理念， Eclipse的微核是OSGi， Spring的微核是BeanFactory，Maven的微核是Plexus， 通常核心是不應該帶有功能性的， 而是一個生命週期和整合容器， 這樣各功能可以通過相同的方式互動及擴充套件， 並且任何功能都可以被替換， 如果做不到微核，至少要平等對待第三方， 即原作者能實現的功能，擴充套件者應該可以通過擴充套件的方式全部做到， 原作者要把自己也當作擴充套件者，這樣才能保證框架的可持續性及由內向外的穩定性。
不要控制外部物件的生命週期
比如上面說的Action使用介面和Renderer擴充套件介面， 框架如果讓使用者或擴充套件者把Action或Renderer實現類的類名或類元資訊報上來， 然後在內部通過反射newInstance()建立一個例項， 這樣框架就控制了Action或Renderer實現類的生命週期， Action或Renderer的生老病死，框架都自己做了，外部擴充套件或整合都無能為力， 好的辦法是讓使用者或擴充套件者把Action或Renderer實現類的例項報上來， 框架只是使用這些例項，這些物件是怎麼建立的，怎麼銷燬的，都和框架無關， 框架最多提供工具類輔助管理，而不是絕對控制。
可配置一定可程式設計，並保持友好的CoC約定
因為使用環境的不確定因素很多，框架總會有一些配置， 一般都會到classpath直掃某個指定名稱的配置， 或者啟動時允許指定配置路徑， 做為一個通用框架，應該做到凡是能配置檔案做的一定要能通過程式設計方式進行， 否則當使用者需要將你的框架與另一個框架整合時就會帶來很多不必要的麻煩， 另外，儘可能做一個標準約定，如果使用者按某種約定做事時，就不需要該配置項。 比如：配置模板位置，你可以約定，如果放在templates目錄下就不用配了， 如果你想換個目錄，就配置下。
區分命令與查詢，明確前置條件與後置條件
這個是契約式設計的一部分，儘量遵守有返回值的方法是查詢方法，void返回的方法是命令， 詢方法通常是冪等性的，無副作用的，也就是不改變任何狀態，調n次結果都是一樣的， 比如get某個屬性值，或查詢一條資料庫記錄， 命令是指有副作用的，也就是會修改狀態， 比如set某個值，或update某條資料庫記錄， 如果你的方法即做了修改狀態的操作，又做了查詢返回， 如果可能，將其拆成寫讀分離的兩個方法， 比如：User deleteUser(id)，刪除使用者並返回被刪除的使用者， 考慮改為getUser()和void的deleteUser()。 另外，每個方法都儘量前置斷言傳入引數的合法性，後置斷言返回結果的合法性，並文件化。