前記
為什麼是再讀？因為在這之前筆者已經閱讀過一遍架構之道這本書，但當時缺乏專案的鍛鍊和試錯，總覺得讀的不深，終於有幸在工作期間接觸到了一些專案和需求，更幸運的是專案組在開發時採用的架構正好是整潔架構，詳細的說，是事件驅動開發DDD+整潔架構，關於DDD的詳細內容將會在之後討論，筆者就重新閱讀了這本書📚，收穫頗豐，因此這一個系列，我準備用自己的拙見描述一下整潔架構，更準確的說，應該是是讀書筆記，以茲同仁。
這本書的詳細地址為：架構整潔之道-羅伯特 C. 馬丁-微信讀書 (qq.com)
本系列會以圖書的章節組織作為思路，跟隨作者的腳步逐漸深入，同時，由於是再讀，所以不可避免的也會穿插一些圖書中其他部分的內容，所以，如果你在閱讀時發現了一些難於理解或者沒聽說過的內容，那它大機率是在之後章節中的內容。
讓我們開始吧。
設計與架構的含義
設計與架構，本質上並沒有區別，底層設計細節和頂層架構資訊共同定義了軟體系統。
軟體架構的終極目標是用最小的人力成本來滿足構建和維護系統的需求，因此成本可以評估一個軟體架構設計的優劣。
沒有經過設計、匆匆構建的系統可能成為亂麻系統，亂麻系統在構建過程中被長期忽視程式碼質量和設計結構最佳化。認真設計軟體架構可以在一定程度上避免系統成為亂麻系統，從而降低成本。
軟體開發具有兩個核心特點：
- 要想跑得快，要先跑得穩；
- 過度自信只會使得重構設計陷入和原專案一樣的困局。
兩個價值維度
軟體系統包含兩種價值：
- 行為價值：讓機器按照某種指定方式運轉，給系統的使用者創造或者提高利潤；
- 架構價值：軟體要夠靈活，更改軟體的成本要做到與需求的範疇相關，與形狀無關。
怎麼理解需求的範疇與形狀？ 筆者自己理解範疇即需求大致的範圍和所屬領域，而形狀指需求的細節內容。
那麼哪個價值維度更重要呢？ 作者認為架構價值比行為價值更重要，因為：
- 如果某程式可以正常工作，但是無法修改，那麼當需求變更的時候它就不再能夠正常工作了，我們也無法通過修改讓它能繼續正常工作。因此，這個程式的價值將成為0；
- 如果某程式目前無法正常工作，但是我們可以很容易地修改它，那麼將它改好，並且隨著需求變化不停地修改它，都應該是很容易的事。因此，這個程式會持續產生價值。
業務部門與研發部門經常犯的共同錯誤是沒有把真正緊急並且重要的功能和緊急但是不重要的功能分開，結果就是重要的系統架構問題讓位給了不重要的系統行為功能。
平衡系統架構的重要性與功能的緊急程度這件事，是軟體研發人員自己的職責。
筆者注：同時，即便同樣是研發人員，不同的小組也會存在類似問題，正如某些前端部門認為後臺只需要提供一系列介面很容易，而不知道良好設計的重要性。
為好的軟體架構持續鬥爭✊
如果忽視軟體架構的價值，系統將會變得越來越難以維護，終會有一天，系統將會變得再也無法修改。如果系統變成了這個樣子，那麼說明軟體開發團隊沒有和需求方做足夠的抗爭，沒有完成自己應盡的職責。