春節假期已經過去，但還是讀了一本書，也不算精讀，把讀後的學習總結與大家分享。本筆記不是書的摘抄，內容是通過筆者閱讀書之後，對知識內容的消化提煉而成，故不敢以此文指導他人學習，但願與讀者多多交流，如有錯誤還望多多指點。
外文技術書翻譯後通常很難理解，此書也不例外，首先，書中對演進式架構的定義就很晦澀 —— 演進式架構是支援跨多個維度進行引導性增量變更的架構。
第一，先多讀幾遍，念順了；
定義中的關鍵字一：多個維度。
所謂多個維度，指的是架構師不要只關注技術維度對架構演進的影響，也要關注資料、安全、運維等緯度的變化影響。除此之外，康威也提醒架構師，還應關注團隊之間的協同緯度的變化影響。在現實情況下，一次組織架構的調整，將很大程度影響著架構演進的路徑。
定義中的關鍵字二：增量和引導。
「增量和引導」是演進式架構包含的兩個關鍵特徵，其中「增量」表達了架構隨時間不斷變化的概念，而「引導」的含義反映了我們期望的架構演進方向。
回到生物學的隱喻，演進是這樣乙個過程：建立乙個適用的並能在其所處的不斷變化的環境中持續執行的系統。
理解了引導的含義，那麼「引導」引導的是什麼？引導的原則又是什麼？
我們知道，安全性、吞吐量、低延遲、故障恢復能力都可以定義為系統的架構特徵，由於這些特徵有的是相互衝突的，比如安全性與效能。所以，對架構師而言，在架構演進過程中需要評估和權衡這些不同的特徵，而所謂引導就是評估這些不同架構特徵，讓架構演進中不隨著時間而磨損掉這些特徵。簡單說，引導就是架構師期望架構具備哪些特徵。
關於引導的原則，本書引入了進化計算中的概念 —— 適應度函式，讓架構師可以通過適應度函式來解釋什麼方案更好，並用它衡量何時能達到目標，但筆者通讀之後，沒有理解，故不過多闡述。
之後，本書又重點介紹了增量變更、架構耦合對演進式架構的影響，內容圍繞持續交付、領域驅動設計、架構演進等方面，內容並不新鮮，故也不做羅列。
如何構建？本書的邏輯是這樣的。
架構耦合很大程式決定了技術架構的演進能力，清晰解耦的架構易於演進，反之則會妨礙演進。回答如何構建演進式架構，我理解的是從微服務架構開始，後面的內容基本也都是在圍繞著微服務和領域驅動設計再說，有興趣的讀者可以去讀一下本書。
演進式架構學習筆記（五） 實踐演進式架構
第8章實踐演進式架構 一 組織 全功能團隊。敏捷軟體開發中的最佳實踐之一。這裡主要需要關注運維角色。圍繞業務能力來組織團隊。產品高於專案。產品生命週期長於專案。增加團隊成員責任感的最佳方式，就是負責到底。應對外部變化。乙個有效的方法是，採用消費者驅動契約的模式。這個模式和solid中的依賴倒置很類似...
企業架構演進
其中的分析階段也就包括了架構設計工作，逐漸又被細分為概要設計和詳細設計。但是這個時期的架構設計主要還是針對軟體設計，還沒有發展出成形的企業架構理論。螺旋模型通過持續對原型進行驗證式 增量交付的方式，彌補 瀑布模型 在需求管理方面不足，是一種對需求的漸進式探索，也加強了對專案風險的管理。敏捷宣言四個核...
架構 第五章 分布式架構的演進
適用於小型 小型管理系統，將所有功能都部署到乙個功能裡，簡單易用。缺點 1 效能擴充套件比較難 2 協同開發問題 3 不利於公升級維護 通過切分業務來實現各個模組獨立部署，降低了維護和部署的難度，團隊各司其職更易管理，效能擴充套件也更方便，更有針對性。缺點 公用模組無法重複利用，開發性的浪費 將各個...