可以將程式分為3部分，乙個是邏輯（logic）；乙個是控制（control）；資料結構（data structures）。邏輯是用來解決實際問題的，也就是具體問題的實現。控制是將多個邏輯組合起來工作的方式，即邏輯組合的策略。資料結構是計算機中儲存、組織資料的方式。程式執行的效率取決於這三者的組合結果。
如果將邏輯與控制有效的分開，那麼給**帶來的是更好的維護性與擴充套件性，也就是更強的生命力。這也就是我理解的最程式架構設計的基礎目標。
資料結構不是不重要，是我理解不夠，暫不做過多說明。
程式設計的本質
2023年，瑞士計算機科學家提出，《algorithms + data structures = programs》 ，即 演算法 + 資料結構 = 程式。
1979 年，英國邏輯學家和計算機科學家 robert kowalski 發表** algorithm = logic + control，即 演算法 = 邏輯+ 控制。
總結上面倆個公式可以得出：程式 = 邏輯 + 控制 + 資料結構我們寫的初始**大多是邏輯與控制區分不那麼明確的，裡面資料結構和流程是跟業務相關的，有些是不相關的。業務需要決定了邏輯的複雜度，業務複雜的邏輯本身就會複雜。但是我們可以通過多層級的多維度的切分，將複雜系統實現的更具有可讀性。在通過恰當的設計模式更合理的設計多模組的互動介面（也界定了接**互資料結構）。進而就有了對應特定場景的架構。
實踐應用
**複雜度的原因：
顯然，上面的業務邏輯我們是控制不了的，我們可以努力解決的就說解耦業務邏輯與控制邏輯。解耦控制與業務我們可以使用下面的技術：
某些特定領域（domain）設計的專用語言(dsl —— domain specific language)
正規化程式設計（是某種程式語言典型的程式設計風格或者說是程式設計方式）
企業架構思考
roger sessions是objectwatch的cto。在紐西蘭teched2009的session arc203 services and complexity 分享了自己關於企業架構的獨特觀點，非常令人印象深刻，無疑可以給大家帶來很多思考。roger認為ea企業架構可以實現的所謂 立即的 ...
企業架構思考
roger sessions是objectwatch的cto。在紐西蘭teched2009的session arc203 services and complexity 分享了自己關於企業架構的獨特觀點，非常令人印象深刻，無疑可以給大家帶來很多思考。roger認為ea企業架構可以實現的所謂 立即的 ...
微服務架構思考
二 從迭代的角度去考慮 服務拆分的缺點 1.每個服務都需要單獨的機器部署，浪費資源,增加運維負擔 2.服務拆分後會產生分布式事務 跨庫事務 跨庫分頁 3.服務較多時，服務之間的依賴關係複雜，不好治理 4.拆分後不便於排查問題，不便於debug 5.特殊業務的服務歸屬問題難以決定，當乙個介面即可以放在...