接著上一次的《架構整潔之道》閱讀筆記02繼續寫最後一篇：
1.軟體開發技術發展的歷史：就是乙個如何想法設法方便地增加外掛程式，從而構建乙個可擴充套件、可維護的系統架構的故事。
2.系統的核心業務邏輯必須和其他元件隔離，保持獨立，其他元件要麼可以去掉的，要麼有多種實現的。
業務邏輯是乙個系統存在的意義，屬於核心功能，是系統用來賺錢或省錢的那部分**，是整個系統中的皇冠明珠。
業務邏輯應該保持純淨，不要摻雜使用者介面或者所用資料庫相關東西。
理想情況下，代表業務邏輯的**應該是整個系統的核心，其它底層概念的實現應該以外掛程式形式接入系統中。
業務邏輯應該是系統中最獨立、復用性最高的**。
常見系統架構，六邊形架構（埠與介面卡架構）、dci架構、bce架構。
1.分層：這些架構都會將軟體切割成不同的層，至少有乙個層是只包含軟體的業務邏輯的，使用者介面、系統介面屬於其他層。
2.**依賴只能使由外向內，內層結構的**不能包含有任何外層結構的資訊
每一種架構一定能在寫系統的業務邏輯的時候有以下特徵：
1、與框架分離：系統架構不依賴於某個功能豐富的框架中的某個函式，框架被當作工具使用，不需要讓讓系統來適應框架。
2、可測試性：系統的業務邏輯可以脫離ui、資料庫、web服務及其他外部元素來測試。
3、與ui分離：ui必須能非常容易獨立地修改。而不能在改變ui的同時需要改變系統其他部分。比如當把系統的ui從web ui改成控制台ui，你並不需要改變任何業務邏輯的**。
4、與資料庫分離：能很方便地在oracle，sql server，mongo db，bigtable，couchdb或者其他資料庫中進行切換和改變。業務邏輯決不能依賴這些資料庫。
5、與外部結構分離：系統的業務邏輯並不需要知道任何外部的結構。
srp（單一職責原則）：每個軟體模組都有且只有乙個需要改變的理由。
適用範圍：方法、類、介面、包、模組、應用(應用的職責)、系統(業務系統的邊界)
ocp（開閉原則）：易於擴充套件、 修改關閉
lsp（黎克特制替換原則）：如果想用可替換元件來構建軟體系統，那麼這些元件必須遵守同乙個約定，以便讓這些元件可以相互替換。
isp（介面隔離原則）：主要告誡軟體設計師應該在設計中避免不必要的依賴。任何層次的軟體設計如果依賴了它並不需要的東西，就會帶來意料之外的麻煩
dip（依賴反轉原則）：依賴關係應該應該多引用抽象型別，而非具體實現
主要是解決元件聚合的問題
原則：復用/發布等同原則、共同閉包原則、共同復用原則。
主要是解決元件耦合的問題
幫助我們確定元件之間的相互依賴關係，要考慮三個原則：無依賴環原則、穩定依賴原則、穩定抽象原則。
adp：元件依賴關係圖中不應該出現環
sdp：依賴關係必須指向更穩定的方向
sap：乙個元件的抽象化程度應該與其穩定性保持一致。
《架構整潔之道》閱讀筆記02
軟體系統可以通過行為和架構兩個維度來實現實際價值 7.1行為價值 包括需求的實現，以及可用性保障 效能 穩定性 是最直觀的價值 7.2架構價值 軟體系統必須靈活，必須容易被修改 7.3架構價值是否是必須要有的？如果業務是明確的 穩定的，架構的價值就可以忽略不計 但業務通常是不明確的 飛速發展的，這時...
《架構整潔之道》閱讀筆記01
我閱讀的第一本名著是電子版的 架構整潔之道 網上對這本書的評價很好，閱讀後我總結了自己的一些閱讀筆記和心得體會，按點論述一下 1.1普通程式設計師 就是正確處理業務和資料計算，讓 跑起來 1.2工程師 寫的 易讀 易維護 易擴充套件 可重用 效率高 1.3架構師 權衡 決策 簡化 靈活 應對複雜度 ...
《架構整潔之道》讀書筆記（二）
在本書的第二部分重新審視了一下三種基本的程式設計正規化 結構化程式設計 物件導向的程式設計與函式式程式設計，並提出了乙個重要觀點 從1946年圖靈為電子計算機寫下第一行 到現在，軟體的基本規則一直沒有變過。電腦程式的最基本構件始終是順序 執行 選擇 遞迴和間接應用 indirection 程式設計正...