呃，前面復習的忘了發了。從后面開始吧
Unit 11--18
復習Tips：
重點在于對概念的理解，概念間關系的理解。
對具體的識別方法，處理方法等根據自己的興趣做一些了解即可 。
如：關于 軟件架構脆弱性的成因 ，
首先要知道軟件脆弱性是什么，然后知道“軟件架構的脆弱 性通常與軟件架構的風格和模式有關”，
至于具體不同架構模式的脆弱性表現，只要根據興趣了解一下就可以，需要舉例子時能舉出來即可。 這八章均是如此要求。
目錄
一、Unit 11-12 軟件架構度量和軟件架構演化 1.1為什么需要進行軟件架構度量？
（軟件架構度量的意義/好處）
軟件架構作為軟件開發的早中期模型，通過對軟件架構進行評估分析，能夠及早的發現軟件開發過程中可能遇到的問題，并提出可行的解決方案，進而提高了軟件質量保障，降低了軟件開發的風險。
1.2軟件度量與軟件演化之間的關系？
通過對演化前后的軟件進行度量，分析相關質量屬性的變化情況，可以得到軟件的內部架構與外在屬性之間的聯系，有利于進一步在總體上把握和控制軟件演化的方向
1.3為什么要進行軟件架構演化？
軟件架構演化的目的為了適應用戶需求、開發環境、運行環境的變化。
一是在開發過程中用戶的需求以及開發環境會發生變化，需要通過改變軟件架構來適應用戶需求的變化以及開發環境的變化；
二是在項目開發完成后，用戶的需求依然可能發生改變，軟件的運行環境也可能會發生變化，需要通過架構演化來適應這一系列變化。
1.4軟件架構演化的類型？
靜態演化：（1）是什么、（2）必要性、（3）一般流程
（1）靜態演化是指開發尚未完成過程中、或者說開發已完成但系統停止運行過程中發生的演化。
（2）在架構開發和實現過程中需要對原有架構進行調整，保證架構與需求之間的一致性
在開發完成后，由于運行環境發生變化，需要對軟件進行修改升級。
（3）架構理解——演化需求分析——演化計劃設計——演化計劃實現——系統測試
動態演化：（1）是什么、（2）必要性、（3）內容以及技術
（1）軟件運行過程中，對系統進行更新，且不停止軟件功能的運行
（2）系統內部執行導 致的系統架構的變更；二是系統外部發送請求對軟件進行重部署
（3）屬性變更、接口變更、拓撲結構變更、架構風格變更，
技術：動態重配置（主從模式、中央控制模式、客戶端-服務端模式）
二、Unit13 軟件架構重構 2.1 軟件架構重構是什么，為什么要進行軟件架構重構
軟件架構重構是指在不改變軟件功能以及軟件可見部分的前提下，對軟件的可維護性、可拓展性等質量屬性進行優化的過程。軟件從架構重構是軟件質量保障的重要手段、是軟件架構演化的重要方式。
2.2 基于度量的軟件架構重構
（1）如何通過軟件架構度量獲取重構需求
（2）如何通過軟件架構度量進行軟件重構建議（如何重構）
（3）基于度量評估的架構重構過程
架構重構一定是在通過度量明確架構缺陷之后才進行的
基于度量對軟件架構進行評估——產生重構需求——分析重構需求——設計重構計劃——執行重構操作
三、Unit14-15 軟件架構腐蝕與軟件架構恢復 3.1什么是軟件架構腐蝕
是指實際開發中的軟件架構與預期的軟件架構之間的差別。軟件架構腐蝕是由于軟件修改產生的，而非人為惡意的。
解決方法（架構腐蝕前：預防腐蝕；架構腐蝕中：減輕架構腐蝕危害；架構腐蝕后：進行腐蝕修復）
3.2什么是軟件架構恢復，有什么意義
軟件架構恢復是逆向工程的實踐和研究的方向。軟件架構恢復是指根據項目工程，完成由低層向高層的抽象過程，得到系統架構中組成元素。開發人員可以根據恢復出的系統架構，對系統的代碼編寫、代碼測試等進一步評估優化。
3.3軟件架構腐蝕和軟件架構恢復之間的關系
隨著軟件開發的進行，難免會產生文檔的缺失，代碼與預期的偏差越來越大（架構腐蝕的定義），進而逐步發生軟件的架構腐蝕。這時候如果人工來閱讀代碼來恢復架構的話，無疑很是費時費力，這個時候通過逆向工程來恢復架構對預防軟件腐蝕就顯得很有意義
四、Unit16-18 技術債、壞味道、脆弱性 4.1 軟件技術債的含義和分類
含義：
指軟件開發人員為了保證項目進展，或因為時間的原因，或因為開發人員本身技術的原因，在該采用某些最優的設計方案時采取了某些妥協，以在短期內加速開發，進而加重自己未來的開發負擔。
分類：
設計債務（沒有采用最優架構）
代碼債務（沒有遵循標準代碼格式等）
測試債務
文檔債務
4.2 軟件技術債的償還
（1）發現技術債
（2）加入產品列表
（3）按照償還的難度以及收益進行排序
（4）在將來開發周期中逐步償還技術債
4.3 軟件壞味道的含義和分類
1.代碼壞味道：程序中某一段代碼是不好的或是不合理的，我們將這一段代碼稱為代碼壞味道。
（1）應用級壞味道：重復代碼
（2）類級壞味道：過大的類
（3）方法級壞味道：過長的方法、參數過多
2.架構壞味道：
連接件嫉妒
模糊接口功能分散
4.4 軟件脆弱性的成因
軟件脆弱性是指在軟件開發過程中（如需求分析，代碼編寫）等過程存在的錯誤，也可能是在配置過程中存在的錯誤。這種錯誤本身并沒有危害，但一旦被攻擊者利用，可能會導致非常嚴重的后果。軟件脆弱性一般與軟件架構風格相關，不同風格的脆弱性不同。比如管道過濾器風格，如果前面幾個過濾器出現錯誤，經過層層過濾，可能會導致錯誤的放大。
最后再簡單總結下：
1.軟件架構度量與演進
（1）軟件架構度量的意義（進行軟件質量保障，降低開發風險）
（2）軟件架構演進的意義（滿足需求，適應環境）
（3）二者之間的聯系
（4）軟件架構演進的分類
2.軟件架構重構
（1）什么是軟件架構重構
（2）軟件架構重構的步驟
3.軟件架構腐蝕與恢復
（1）什么是軟件架構腐蝕
（2）什么是軟件架構恢復
（3）腐蝕與恢復之間的聯系
4.軟件架構技術債、壞味道、脆弱性
（1）什么是軟件架構技術債
（2）如何償還技術債
（3）有哪些壞味道
（4）軟件脆弱性的成因及危害
軟件架構分層，你的項目處于什么階段？
前言
只要從事軟件開發的工作，系統架構是必備知識。有朋友說可能會說，我只是一個搬磚的，怎么會接觸到架構知識呢？其實，除了架構的設計者（也就是架構師），作為普通的開發者也是在時刻踐行著系統架構的理論。畢竟，再好的架構，都需要碼農去實施。只不過當你沒有系統了解軟件架構時，可能感知不到而已。
本篇文章就帶大家系統的了解一下軟件架構的分層，學習完畢，你就會明白，為什么系統要分層。同時，也能準確的看清楚目前自己系統中采用的是什么樣的分層架構。
不采用架構分層，行不行？
首先我們來思考一個問題，如果一個系統不采用分層架構可不可以？這個問題就好像在問，代碼中不使用設計模式行不行？答案當然是可以的。但不采用架構分層，會帶來極大的未知風險，或者說代碼極具熵增的特性。
作為一個初創軟件，可能沒有什么業務邏輯，沒有什么用戶量，而軟件最主要的目標就是快速上線，實踐商業模式。此時，可以不考慮分層。但隨著業務邏輯的復雜，業務板塊的增多，彼此之間就會出現錯綜復雜的依賴關系，隨之就會產生的邏輯不清晰、可讀性差，維護困難，改動一處動全身等問題。
什么是架構分層？
分層架構是將軟件模塊按照水平切分的方式分成多個層，一個系統由多層組成，每層由多個模塊組成。同時，每層有自己獨立的職責，多個層次協同提供完整的功能。比如，我們經常提到的MVC架構，就是一種非常典型非常基礎的分層方式。
分層設計的本質其實就是將復雜問題簡單化，基于單一職責原則讓每層代碼各司其職，基于“高內聚，低耦合”的設計思想實現相關層對象之間的交互。從而，提升代碼的可維護性和可擴展性。
系統架構分層之后，往往需要達到以下目標：
通訊領域的OSI參考模型
在計算機領域現有最典型的分層架構設計就是OSI參考模型和TCP/IP參考模型了。關于這個模型，我們在《》一文中已經詳細介紹了。下面直接看一下相關的模型圖：
對于上述的三種分層模式，試想一下，如果沒有分層，當一個業務或協議需要改變時，我們只能針對整個系統做修改或擴展。而分層之后，便可以很方便的把不同功能的模塊抽離出來，修改對應的模塊即可。而且不同層還可以被復用，只要確保按照這個層的協議來處理就可以了。
軟件系統整體分層
以Java軟件應用為例，整個軟件系統也可進行分層，比如分為部署的硬件環境、操作系統、所需的中間件、承載業務的應用程序以及軟件接入層。可通過下圖進行整體了解：
對于上述分層也產生了對應在職位，比如運維工程師、中間件工程師、產品經理、開發工程師、測試工程師等工種。而我們在實踐過程中，接觸最多，使用最多的分層要屬應用軟件層了，其次是中間件層。
下面我們就來看看針對應用軟件層通常有哪些分層方式。
經典三層架構
三層架構(3-tier ) ，通常就是將整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。
表現層（UI），通俗講就是展現給用戶的界面，對應項目中的Web層包含Servlet和等。
業務邏輯層（BLL）：也稱作領域層，負責系統業務邏輯的處理，對應項目中Service和等。
數據訪問層（DAL）：該層所做事務直接操作數據庫，針對數據的增添、刪除、修改、更新、查找等，對應項目中的Dao。
在提出該分層架構的時代，多數系統往往較為簡單，本質上都是一個單體架構（ ）的數據庫管理系統。這種分層架構已經是Client-Server架構的進化了，它有效地隔離了業務邏輯與數據訪問邏輯，使得這兩個不同關注點能夠相對自由和獨立地演化。
在開源技術框架中，表現層實現的代表作品是Struts1/2、Spring MVC，業務層實現的代表作品是Spring，持久層實現的代表作品是和Mybatis。
MVC
MVC全名是Model View ，是模型(model)－視圖(view)－控制器()的縮寫，一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。MVC被獨特的發展起來用于映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。
標準的MVC交互模型如下圖：
View：視圖，為用戶提供使用界面，與用戶直接進行交互。
Model：模型，承載數據，對用戶提交請求進行計算的模塊。分為兩類，一類稱為數據承載Bean，一類稱為業務處理Bean。數據承載Bean是指實體類，專門承載業務數據的，如Student、User等。而業務處理Bean則是指Service或Dao對象，專門用于處理用戶提交請求的。
：控制器，用于將用戶請求轉發給相應的Model進行處理，并處理Model的計算結果向用戶提供響應。
從圖中可以看到，標準的MVC中模型能主動推數據給視圖進行更新（觀察者設計模式，在模型上注冊視圖，當模型更新時自動更新視圖），但在Web開發中模型是無法主動推給視圖（無法主動更新用戶界面），因為在Web開發是請求-響應模型。
Web MVC標準架構，如下圖所示：
在Web MVC模式下，模型無法主動推數據給視圖，如果用戶想要視圖更新，需要再發送一次請求（即請求-響應模型）。MVC用于將web（UI）層進行職責解耦。
三層架構和MVC的區別與聯系
MVC嚴格說是三層架構中的UI層，也就是說，MVC把三層架構中的UI層再度進行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話，而C層直接與三層中的BLL進行對話。
三層架構和MVC可以共存。三層架構是基于業務邏輯來分的，而MVC是基于頁面來分的。MVC是表現模式（ Pattern），三層架構是典型的架構模式（ Pattern）。
三層架構的分層模式是典型的上下關系，上層依賴于下層。但MVC作為表現模式是不存在上下關系的，而是相互協作關系。即使將MVC當作架構模式，也不是分層模式。MVC和三層架構基本沒有可比性，是應用于不同領域的技術。
阿里四層架構
三層架構實現比較簡單，很多朋友可能覺得項目分層就應該如此，結果就是往往會出現一大堆的業務邏輯都堆砌在Service層中。而在《阿里巴巴 Java 開發手冊 》中將原來的三層架構進一步細化，添加了Manager通用業務處理層。
Manager層可以將原Service層的一些通用能力進行下沉，比如與緩存和存儲交互策略，中間件的接入；還可以封裝對第三方接口的調用，比如調用支付服務，調用審核服務等RPC接口。
通用業務處理層，它有如下特征：
其各層的作用如下：
系統工程結構
在學習了以上分層架構之后，下面來看一下針對分層在軟件系統中的對照關系表：
以上分層定義僅供參考。在上表中還多出了對外接口層和接入層。
對外接口層：所有對外的接口放在這層，不能包含任何業務邏輯，只數據對象的轉換和異常的封裝。
接入層：所有外部系統的依賴放在這層，好處是一旦外部系統接口修改，只需要在一處修改即可。
DDD分層架構
DDD是一種處理高度復雜領域的設計思想，試圖分離技術實現的復雜性，同時圍繞業務概念構建領域模型，提出的一種軟件架構設計的方法論。
DDD分層架構將數據、緩存等都視為基礎層， 可以被所有層調用；抽離了領域層，負責核心業務邏輯處理，領域層調用外部依賴全部通過接口，以保證領域層的100%單測覆蓋率；應用層聚合多個領域層的能力，只做功能的組合、轉發，不負責具體業務邏輯。
我們這里只做DDD分層架構的簡單介紹，關于DDD概念不做過多拓展，相關架構模式可專門進行學習一下。看一下DDD分層的架構圖：
其中對應層的功能介紹如下：
接口層（）：該層包含與其他系統交互的所有內容，如Web服務器、RESTful接口。接口層處理傳入數據的解釋、校驗、編解碼、序列化操作，同時可以考慮引入專門的DTO（數據轉換對象）來協助數據轉換；
應用層（）：該層負責驅動應用程序完成工作流程。很薄一層，協調多個領域對象(實體、聚合根、領域服務)實現服務編排和組合完成工作流，該層通常不應該包含具體業務邏輯。該層涉及：其他微服務RPC調用、微服務編排和組合、分布式事務實現、消息驅動事件的驅動、日志記錄等。
領域層（Domain）：該層是軟件的核心，包含業務邏輯具體實現，包含實體、值對象、聚合、領域服務、倉儲接口等領域對象內容，通常該層應該配備圖示告知軟件是如何工作的；
基礎層（）：包含網關、緩存、數據庫存儲、消息中間件、監控、應用程序服務等通用的技術和基礎服務。基礎層以不同方式支持到其他三層，促進各層間通信。配置文件、數據庫Schema模式定義以及倉儲接口實現都是基礎結構的一部分；
DDD分層架構傳統三層架構的比較
DDD四層架構也基于傳統三層架構的，看一下它們之間的對照關系：
DDD四層架構和傳統三層架構有以下區別：
關于DDD架構分層還有整潔架構和六邊形架構兩種形式，這里就不再拓展，感興趣的朋友可自行查找相關資料進行學習。
小結
本篇文章為大家講解了市面上常見的架構分層。分層架構的目的是通過關注點分離來降低系統的復雜度，同時滿足單一職責、高內聚、低耦合、提高可復用性和降低維護成本。但分層架構同樣也有一定的缺點，比如開發成本高、性能略低、可擴展性低等問題。實踐中，可根據需要選擇合適的分層架構。