函式式程式語言中的變數是不可變的。
為什麼不可變性是軟體架構設計需要考慮的重點呢？為什麼軟體架構師要操心變數的可變性呢?
答案顯而易見:所有的競爭問題、死鎖問題、併發更新問題都是由可變變數導致的。如果變數永遠不會被更改，那就不可能產生競爭或者併發更新問題。如果鎖狀態是不可變的，那就永遠不會產生死鎖問題。
換句話說，一切併發應用遇到的問題，一切由於使用多執行緒、多處理器而引起的問題，如果沒有可變變數的話都不可能變化。
一種常見方式是將應用程式，或者是應用程式的內部服務進行拆分，劃分為可變的和不可變的兩種元件。
不可變元件用純函式的方式來執行任務，期間不更改任何狀態。
這些不可變的元件將通過與乙個或多個非函式式元件通訊的方式來修改變數狀態。
由於狀態的修改會導致一系列併發問題的產生，所以我們通常會採用某種事務型記憶體來保護可變變數，避免同步更新和競爭狀態的發生。
事務型記憶體基本上與資料庫保護磁碟資料的方式類似，通常採用事務或者重試機制。
乙個架構設計良好的應用程式應該將狀態修改的部分和不需要修改狀態的部分隔離成單獨的元件，然後用合適的機制來保護可變數。
軟體架構師應該著力於將大部分處理邏輯都歸於不可變元件中，可變狀態元件的邏輯應該越少越好。
隨著儲存和處理能力的大幅進步，現在擁有每秒可以執行數十億條指令的處理器，以及數十億位元組記憶體的計算機已經很常見了。而記憶體越大，處理速度越快，我們對可變狀態的依賴就會越少。
這三個正規化都對程式設計師提出了新的限制。每個正規化都約束了某種編寫**的方式，沒有乙個程式設計正規化是在增加新能力。
軟體構建並不是乙個迅速前進的技術。今天構建軟體的規則和2023年阿蘭.圖靈寫下電子計算機的第一行**時是一樣的。儘管工具變化了，硬體變化了，但是軟體程式設計的核心沒有變。
總而言之，軟體，或者說電腦程式無一例外是由順序結構、分支結構、迴圈結構和間接轉移這幾種行為組合而成，無可增加，也缺一不可。
《架構整潔之道》之程式設計正規化總覽
結構化程式設計是第乙個普遍被採用的程式設計正規化 但是不是第乙個被提出的 由edsger wybe dijkstra於1968年最先提出。與此同時，dijkstra還論證了使用goto這樣的無限制跳轉語句將會損害程式的整體結構。結構化程式設計正規化歸納 結構化程式設計對程式控制權的直接轉移進行了限制...
《架構整潔之道》之結構化程式設計
dijkstra很早就得出的結論是 程式設計是一項難度很大的活動。一段程式無論複雜與否，都包含了很多的細節資訊。如果沒有工具的幫助，這些細節的資訊是遠遠超過乙個程式設計師的認知能力範圍的。而在一段程式中，哪怕僅僅是乙個小細節的錯誤，也會造成整個程式出錯。dijkstra提出的解決方案是採用數學推導方...
《架構整潔之道》之元件聚合
軟體復用的最小粒度應等同於其發布的最小粒度。從軟體設計與架構設計的角度來看，復用 發布原則就是指元件中的類與模組必須是彼此緊密相關的。也就是說，乙個元件不能由一組毫無關聯的類和模組組成，它們之間應該有乙個共同的主題或者大方向。從另乙個角度來看，這個原則就沒有那麼簡單。因為根據該原則，乙個元件中包含的...