業務系統建立之初，一般會對基礎架構進行選型，整合若干個業界常用的框架後，系統便能夠在一段時期內，較爲快速地支撐一些業務場景，見下圖。
隨着需求不斷新增和變化，業務場景變多，變複雜。在現有框架難以支撐其需求邏輯的情況下，業務代碼的冗餘操作會越來越多，最終導致開發效率和質量的雙下降，見下圖。
因此，投入一定資源長期地去維護、更新框架，保持框架活力，能起到事半功倍的效果。所謂的框架，不僅限於緩存中間件、數據庫中間件、網絡傳輸組件等開源軟件，也包括能解決實際業務問題的自研框架。
這裏說的實際業務問題，不僅僅是那些需求內容，當系統升級到一定規模，就會出現一些非功能性的痛點，而且隨着時間推移，痛點會轉化爲系統發展的瓶頸，接下來以CRM爲例，具體說明。
1、規則框架，業界更多稱爲規則引擎
CRM系統可以說遍地都是規則。一旦選擇把規則“翻譯”到代碼裏，代碼就是上帝。程序員就多了一項工作，把代碼“翻譯”回規則以便客戶瞭解。這種“翻譯”工作是純人工的，容易失真、缺失甚至發生錯誤，最終系統升級就錯上加錯。因此規則的不可見性成爲痛點，也就需要有對應的框架去解決，較爲有名的是開源的drools（另一篇《drools的懶加載和執行》有分享簡單實踐），難度再高一點的，有用antlr來構建規則語言，後面我會另起一篇來分享個人實踐。
2、配置框架
規則一多，爲簡化調整工作，少改點代碼，配置應運而生。出於便捷性、友好性、可操作性、版本管理等等方面的考慮，業務系統可以配套引入或開發一些配置界面，然後後端輕量化地實現配置刷新，版本管理等等。
3、任務框架
上文提到的幾點，雖然重點在描述框架，但業務代碼也同等重要。我個人是比較贊同敏捷軟件開發提到的原則——“最好的架構，需求，和設計出自於自我組織管理的團隊”，每一位開發都要有義務和能力參與到編寫框架和業務代碼的工作中，業務代碼產生價值，框架服務於業務代碼。兩者在物理上是分包隔離的，但在使用場景上又是連續的。因此沒有跑題哈，還是從系統整體來描述設計思路。