最近開始看了《架構整潔之道》，對下面這個圖比較有感觸，就拍了上傳作為記錄下。
這本書給我的感覺是自己原來根本不會設計程式，原來程式的設計不單是功能的實現和框架的使用，編寫程式雖然不是必須要這麼做，但好的程式設計一般是需要遵守一定的設計規則的。下面的這張圖讓我對架構整體設計有了新的認識。
之前用別人的框架總是不是很明白為何那樣分層，到底作者是怎樣思考的。例如entity、service層的設計，而且不同的框架即使採用一樣的設計模式，對程式的分層也是不一樣的。
業務實體
原來以為最重要的是控制器層，但現在看來，專案最核心的還是業務實體部分，因為其封裝了最通用、最高層的業務邏輯。最不容易受到變動影響。業務實體既可以是乙個帶有方法的物件，也可以是椅子資料結構和函式的集合。只要能被系統其他部分復用就可以。
用例
用例層通常包含特定應用場景下的業務邏輯，該層封裝並實現整個系統的用例。引導資料在業務是實體間的流入流出。用例層應該與資料庫、ui等保持隔離。應用行為的變化一定會影響到用例，所以用例的細節產生了變化，自然會影響用例層的**。
架構整潔之道 軟體架構 三
24 謙卑物件 謙卑物件實質是為了找出不可測試的物件，進而確定邊界。而找出不可測試的物件，最終是為了區分對應的可測試物件，並讓其負責更多的決策，比如資料結構，控制變數。從而對決策進行測試，保障系統的準確。而剩下的不可測試的物件，只能安分的聽從可測試物件的決策的安排進行約定的行為。25 不完全邊界 1...
架構整潔之道筆記（一） 概述
架構和設計這兩者有區別嗎？架構 這個詞往往使用於 高層級 的討論中，這類討論一般都把 底層 的實現細節排除在外。而 設計 一詞，往往用來指代具體的系統底層組織結構和實現的細節。但是，從乙個真正的系統架構師的日常工作來看，這樣的區分是根本不成立的。底層設計細節和高層架構資訊是不可分割的，它們組合在一起...
《架構整潔之道》閱讀筆記03
接著上一次的 架構整潔之道 閱讀筆記02繼續寫最後一篇 1.軟體開發技術發展的歷史 就是乙個如何想法設法方便地增加外掛程式，從而構建乙個可擴充套件 可維護的系統架構的故事。2.系統的核心業務邏輯必須和其他元件隔離，保持獨立，其他元件要麼可以去掉的，要麼有多種實現的。業務邏輯是乙個系統存在的意義，屬於...