• 演進能力是一種元特征和保護其他所有架構特征的架構封裝器
• IEEE 的軟件架構定義中的4+1
  視圖模型。它關注不同角色的不同視角，將整個系統劃分成了邏輯視圖、開發視圖、進程視圖和物理視圖
• 架構師確定了可審計性、數據、安全性、性能、合法性和伸縮性是該應用的關鍵架構特征。隨著業務需求不斷變化，每個架構特征都通過適應度函數來保護其完整性。
• 康威描述道，在設計的最初階段，人們首先需要高瞻遠矚地思考如何將職責劃分為不同的模式。團隊分解問題的方式會左右他們之后的選擇，這便是康威定律。
  康威特別提醒軟件架構師，不要只關注軟件架構和設計，還應關注團隊之間委派、分配和協調工作的方式。
• 演進式架構主要由三方面構成：增量變化、適應度函數和適當的耦合

適應度函數:

• 全系統適應度函數允許架構師通過統一的機制思考不同的問題，捕捉和保留重要的架構特征。
• 原子適應度函數與整體適應度函數、觸發式適應度函數與持續式適應度函數、靜態適應度函數與動態適應度函數、自動適應度函數與手動適應度函數\臨時適應度函數、針對特定領域的適應度函數
  盡早確定 適應度函數、預設式高于應急式、審查適應度函數

實施增量變更:

只有成功完成了架構設計、實現、升級和無法避免的變更后，甚至當架構能夠經受由前期未知的未知因素引起的反常事件（第6 章將介紹）帶來的考驗時，架構師才能評價架構的長期有效性
驅動敏捷軟件方法論的引擎是內置的反饋環，如測試、持續集成和迭代等。然而包含應用程序最終用戶的反饋環已經脫離了團隊的控制。使用假設驅動開發，我們能以一種前所未有的方式將最終用戶納入構建流程，從他們的行為中學習并構建出對其真正有價值的系統

架構耦合:

• 模塊化-模塊意味著邏輯分組，而組件意味著物理劃分。
• 架構的量子和粒度-架構量子則是具有高功能內聚并可以獨立部署的組件，它包括了支持系統正常工作的所有結構性元素。在單體架構中，量子就是整個應用程序，每個部分都高度耦合，因此開發人員必須對其進行整體部署。微服務架構在架構元素之間定義了物理限界上下文，封裝了所有可能變化的部分。這種架構就是為了增量變更而設計的。
• 不同類型架構的演進能力
  -大泥團-非結構化單體、分層單體、模塊化的單體架構、微內核架構、事件驅動架構
• 微服務架構通常遵循以下七個原則：
  1-圍繞業務領域建模，微服務的目標是創建有用的限界上下文，而不是讓開發人員構建更小的服務
  2-隱藏實現細節，微服務的技術架構封裝在基于業務領域的服務邊界中。每個領域形成一個物理限界上下文。服務間通過傳遞消息或資源來集成，而不是通過暴露實現細節集成
  3-自動化文化，支持持續交付
  4-高度去中心化，微服務形成了一種無共享架構，其目標是盡可能地減少耦合。通常重復好于耦合
  5-獨立部署，可以獨立部署每個服務（包括基礎設施），反映了服務間的物理限界上下文
  6-隔離失敗，每個服務都應該處理合理的錯誤場景并在可能的情況下將其恢復。
  7-高度可觀察
• 微服務的主要目標是通過物理限界上下文來隔離領域及理解問題領域。因此，它的架構量子就是服務，這使得它成為了演進式架構的優秀示例
  常用于遷移的架構是基于服務的架構，有三個明顯的區別，分別是服務粒度、數據庫范圍和集成中間件。
  更大的服務粒度、數據庫作用域、集成中間件
• 基于服務的架構內在的演進能力肯定比ESB 驅動的SOA 架構要好。開發人員偏離限界上下文的程度決定了架構量子的大小和破壞性耦合的數量。
• “無服務”架構-BaaS（后端即服務）是那些明顯或從根本上依賴于第三方應用或云端服務的應用、FaaS（功能即服務）

演進式數據:

• 是經過檢驗的、版本化的和增量的
• 架構師必須考慮應用的所有耦合特征，其中包括類、包/ 命名空間、庫、框架、數據庫模式，以及事務上下文。在架構演進時，忽視其中任一維度（或維度間的交互）都將產生問題。
• 在將單體架構遷移到某種更精細的架構時，應該從分離少量較大的服務開始。當構建一個全新的微服務架構時，開發人員應該盡量限制服務和數據上下文的大小。然后，不要僅按字面意思來理解微服務，對每個服務而言，小并不是必需的，能捕獲有用的限界上下文才是關鍵。
• 數據的年齡和質量,識別真正有用的數據并將其保留下來，將舊數據作為參考但不將其納入演進式開發的主流。

構建可演進的架構:

• 演進機制-通過下面三步來構建演進式架構
  識別受演進影響的架構維度、為每個維度定義適應度函數、使用部署流水線自動化適應度函數

• 賦予現有架構演進能力取決于三個因素：組件耦合度、工程實踐成熟度，以及開發人員構建適應度函數的難易程度。

• 團隊可以通過多種劃分方式將單體應用分解成服務。業務功能分組、事務邊界、部署目標

• 演進模塊間的交互-拆分共享的依賴、通過JAR文件共享依賴、復制共享的庫以消除耦合點。共享就是耦合的一種形式，在微服務架構中這是非常不可取的

• 演進式架構構建指南-去除不必要的可變性、讓決策可逆、演進優于預測、構建防腐層、服務模板、構建可犧牲架構、應對外部變化，傳遞依賴管理被視為有害的、更新庫與更新框架、持續交付優于快照、服務內部版本化

• 演進式架構的陷阱和反模式-
  為供應商為王反模式-無論從技術還是從業務流程的角度來看，將外部工具或框架置于架構的核心會嚴重限制架構的演進能力

• 陷阱：抽象泄漏 底層抽象破壞會導致意外的災難，即原始抽象泄漏，它是技術棧日漸復雜帶來的副作用之一。

• 反模式：最后10%的陷阱 在抽象范圍的另一端存在著另一種復用陷阱，它隱藏在套裝軟件、平臺和框架中。

• 反模式：代碼復用和濫用-開發人員為實現可復用所添加的鉤子越多，對代碼的基本可用性損害越大。

• 微服務避免代碼復用，遵循重復優于耦合的理念。

• 當耦合點妨礙了演進或其他重要的架構特征時，通過分叉或重復來打破耦合點。
  架構師必須持續評估架構特征的適應度，保證它們仍在提供價值，避免淪為反模式。

• 陷阱：簡歷驅動開發 不要為了架構而構建架構，構建架構是為了解決問題。在選擇架構前，要始終理解問題域，不要本末倒置。

• 增量變更 反模式：管理不當

• 當開發人員構建單體架構時，管理決策將影響所有項目。因此，在選擇數據庫時，架構師必須了解每個項目需要的能力，并考慮最復雜的情況。

• 陷阱：發布過慢 ，一個項目的生產周期決定了架構的演進速度。換句話說，演進速度和生產周期成正比

• 業務問題 陷阱：產品定制 為每個客戶定制、永久的功能開關、產品驅動定制化

• 反模式：報表

• 陷阱：規劃視野

實踐演進式架構：

• 以領域為中心的團隊應該是全功能的，這意味著每個項目角色都由該項目組成員承擔
• 架構師設計架構來消除不當耦合，以簡化增量變更。、全功能團隊的目標之一便是消除協調摩擦
• 圍繞業務能力組織團隊：按照業務能力而非職能來組織團隊
• 產品高于項目
• 團隊成員間的連接數：盡量減少開發團隊之間的連接數。
• 團隊的耦合特征-文化、事不過三，三則重構
• 試驗文化-從外部吸收想法、鼓勵明確的改進、進行探針試驗并穩定下來、創造創新時間、采用基于集合的開發方式、連接工程師和最終用戶
• 公司為何決定構建演進式架構
  可預測性與可演進性、規模、高級業務能力、以生產周期為業務指標