一、什麼是軟體架構

　　軟體架構的設計分為三個部分：元件切分，元件的組合，元件的通訊。

　　軟體架構的最高優先順序時保持系統正常的工作。

　　一個優秀的軟體架構應該時易理解，易修改，方便維護，並輕鬆部署。

1. 開發

　　從開發角度來講一個高質量的軟體架構方便開發的。但是不同的團隊適用不同的軟體架構。

1. 部署

　　一個系統的部署成本越高可用性越低，一鍵部署是設計軟體架構的目標。

1. 執行

　　硬體問題可以由摩爾定律來解決，當在效能和可讀性做選擇的時候可以考慮可讀性。

1. 維護

　　文中講解了 探祕 和風險。探祕就是對現有功能完善和改進。風險就是對功能的完善和改進引入新的問題的風險評估。

1. 保持可選項

　　在設計軟體架構的時候保留多的策略，比如使用redis，還是使用Memcache,或者使用第三者，在應用時應該時以策略為基本元素，讓細節與策略脫離關係。

　　這樣的設計更多的是在專案後期可以使用更多的資訊來進行合理的判斷。

　　所以一個優秀的架構師應該師致力於最大化的可選項的數量。

在設計架構應該做到策略和細節分離，儘可能得到更多的資訊得到一個相對更合適的設計。

二、獨立性

1. 系統的用例

(1) 架構最終是為了實現業務功能，所以架構必須可以滿足業務功能的所有操作，否則架構本身的設計在完善沒有任何意義。

(2) 用例更多的是需求本身。

1. 執行

(1) 可以靈活應對變化，不僅是對系統行為的變化，還有對系統執行要求的變化。

(2) 在應對不同請求時 可以通過分別部署的方式來減少非熱點業務的浪費。

1. 開發

(1) 軟體架構的影響之一就是組織架構，軟體架構是由組織架構決定的，軟體架構合理，組織架構不合理時需要調整相應的組織架構。

1. 部署

(1) 快速部署是架構設計的目標。儘可能地避免依賴配置檔案和指令碼。

1. 保留可選項

(1) 軟體系統都會隨著時間的推移需要不斷的迭代和演進，因為業務是在不斷的優化和改良的。

(2) 在設計系統之初我們要儘可能的確認目標和範圍，儘可能的保證系統職責的所在，以免被變化的需求影響。

(3) 一個設計良好的系統應該通過保留可選項的方式，讓系統在任何情況下都可以方便的做出選擇。所以架構設計應該解決的問題不是限制開發。

1. 按層解耦

(1) 正確規劃專案中每個專案的職責。在mvc專案中 資料庫的操作放到資料倉儲中。業務操作放在controller中，頁面操作就是view，每一個領域劃分清晰。這樣決定了後續系統的複雜度。

1. 用例的解耦

(1) 更像是一種策略模式 一種是v 1.0 另一種是 v2.0 但是v2.0 的業務實現不引用v1.0的業務實現。但是決定這種模式的前提是v1.0的方法中的職責是單一的。

1. 解耦的模式

(1) 微服務是一種常見的解耦的方式。但是微服務需要注意拆分的粒度，並不是拆分越細越好，也不是粗獷的拆分。

三、劃分邊界

1．設計架構應該遵循簡單、合適、演進這三個原則

2．對於複雜度比高的系統級方案可以延後在當前業務發展之後可能這種方案並非是一種完美的解決方案。

3．對於資料處理來講不論是哪一種資料庫，但是與業務實現資料操作介面都是一樣的，比如當前系統使用到的是sql server 根據業務方要求需要換成 mysql ，對於ORM框架來講只需要調整資料操作介面的策略，使對應的是mysql.

4．劃分邊界的前提是，首先要遵從設計原則，然後拆出核心元件。

四、邊界刨析

1．跨邊界呼叫

（1）在微服務中的跨服務呼叫可以簡單的稱之為跨邊界呼叫。

（2）為什麼要畫邊界?邊界的劃分是為了系統的穩定，比如領域的邊界或者服務的邊界，對外看來它是相對穩定的，將變更圈禁止於內部。對於呼叫者和被呼叫者來說都存在互動都是一個獨立的個體，對方的變化不直接影響到被呼叫者的內部變化。