敲了多年的業務代碼，維護過一個持續迭代7、8年的業務應用，對業務應用中的各種if、else 是深惡痛絕，當看到大牛的關於 復雜代碼應對之道，是深表贊同。參考以下兩篇文章：復雜性應對之道 COLA 4.0：應用架構的最佳實踐，
對於復雜的應用，專家提出了2個主要的解決辦法：1.DDD領域建模，2. 分層架構
復雜性來源
對於復雜性，專家提出了主要來源：用面向對象語言，去寫面向過程的業務代碼。個人對此是認同的，業務代碼天然就是過程式的。
但同時也有其他的客觀因素。
對於傳統行業、小應用，業務代碼一般是大量低水平外包程序員寫的，幾乎從始至終沒有考慮過復雜性，后續改造問題，完成功能交付第一。
互聯網大廠，程序員一般科班出身，基礎知識扎實，水平高。然互聯網行業實行敏捷開發，快速試錯迭代，程序員需要滿足產品的各種亂碼星空的想法，往往會陷入各種急迫的需求開發的泥潭，沒時間去重構代碼。時間一久，加上本身業務就比較復雜，還要背負各種高可用指標KPI，幾乎就沒什么勇氣去做代碼重構了。
解決復雜性方法
理論與框架，源於日常的開發的提煉於總結。 日常開發中，我們其實做了很多來應對復雜性。
底層代碼： 重構，設計模式
資源組織： 分包，分模塊，按規則命名（統一前綴、后綴）
服務SOA：微服務
總結就是2條： 1.分治，把大的拆小。 大應用拆分多個應用，微服務調用，MQ異步調用。 單應用分模塊，分包。
2. 約定形成共識。 包、類、方法的命名，資源的存放目錄等，由約定形成共識，減少溝通閱讀的成本。
我們的目的，是要達到一目了然的清晰。
借用一下專家的圖，就是：
COLA 框架到底是什么？
COLA是Clean Object-Oriented and Layered Architecture的縮寫,代表“整潔面向對象分層架構"，這是作者的定義。 經過快速的迭代，演進，目前是4.0版本。架構的代碼比較簡單，沒有復雜的概念與算法，只要花上1個上午就可以全部搞明白。
cola 4 本質就是：規范+可復用組件+鼓勵充血Domain模型！
規范包括：java 文件、包、子模塊的命名規范。
可復用的組件：日志攔截處理，異常定義與處理， 狀態機，業務擴展點設計
最吸引我的就是這個業務擴展點設計，這也是解決業務復雜度，將面向過程的業務處理邏輯 面向對象化的核心所在。但這個又非常的依賴 的命名規范 與 Domain實體。
這個擴展點 大概就是設計模式里面的 策略模式吧，一個擴展點，就是一個精確的執行策略。
COLA 帶來的問題、使用建議
COLA 框架帶來一個非常典型的缺點（問題）： domain 實體類爆炸！
命名規范中查詢用Qry結尾，增刪改用 CmdExe結尾，返回結果用Response ,每個業務方法來一套，還有各種Item、VO、BO、CO、DO，有些字段需要重復非常多遍，各種實體類的轉換也是非常多的重復代碼，多層次的轉換鏈條，中間有1個斷了，都沒法輸出正確。看看框架自帶的Demo代碼，大概5個實體表，sample代碼里面的實體對象就快50個左右了。。
COLA框架，本質上沒有 什么嚴格的約束，對於業務代碼，還是有非常好的指導建議，不一定非要嚴格的按照框架的要求來執行，但一定要有規范的思想，這才是核心的。
實際開發中，做好分模塊，分層次，做好命名規范+一定的充血模型，用好 擴展組件點的策略模式，相信代碼就能做到簡潔易懂！