軟件架構介紹

此文介紹軟件的架構                                        

什么是軟件架構以及為何我們需要它?

就如同其他復雜結構一樣，軟件必須要建構在一個堅實的基礎之上。沒有考慮到關鍵場景，沒有針對常見問題的設計，或者沒有考慮一些重要決定帶來的長期結果，就會將你的軟件應用程序置于危險之中。代碼沒有架構，就如同花園中的常青藤，會變得很難維護，添加新特性也困難。

軟件架構是一個技術藍圖，詮釋了在優化諸如軟件性能，安全性以及可管理性等常見的屬性時候系統是如何由子系統（模塊）構建的。

Philippe Kruchten, Grady Booch, Kurt Bittner以及Rich Reitman在Mary Shaw and David Garlan (Shaw and Garlan 1996)的成果基礎上延伸并提煉出了對軟件架構的定義。他們是這么定義的:

軟件架構包含關于一個軟件系統組織結構方面的諸多重要決策，包括如何選擇系統構成的結構元素以及結構；那些元素間協作的特定行為；這些結構以及行為元素如 何組成一個更大的子系統；指引這個組織結構的架構風格。軟件架構還包含功能性，可用性，適用性，軟件性能，重用性，經濟以及技術方面的限制，折中方案以及 美學等諸多方面的考量。

在Patterns of Enterprise Application Architecture 中，Martin Fowler 概括了一些解釋架構是經常提到的主題。他認為這些主題是：

一個系統在最高級別上分解為多個局部；不易變化的決定；一個系統可以有多個架構；明顯架構化的東西也會在一個系統的生命周期里變化；最后，架構歸結為任何重要的東西。

在 Software Architecture in Practice (2nd edition )中，Bass, Clements 和 Kazman 這樣定義架構：

一個程序或計算機系統的軟件架構是指系統的一個結構或多個結構，它們組成軟件元素，元素的外部可見性，元素間的關系。架構關心公共接口；元素的私有細節——內部實現的細節——不是架構。

架構的目標是識別出影響應用結構的需求。優秀的架構能減低構建一個技術解決方案的業務風險。優秀的設計是足夠靈活的，可以應對隨時變化的硬件與軟件技術，以及用戶場景與需求。

軟件架構提供了一些益處，包括：

• 更高的生產效率。 結構確定了，那就更容易想已有的軟件添加新個性，而且每一處新代碼的位置都是事先知道的。

• 更好的代碼可維護性。 代碼結構可見和已知，那就更容易維護已有的軟件，所以也更容易找到 bug 和異常現象。

• 更高的適應性。 軟件架構事先考慮到清晰的分離，那就更容易完成諸如換一個前端，添加業務規則引擎等新技術特性。

• 宣揚不可知論。 最后，不過不是必然，軟件架構能使你根據你當前的結構看到行業里大肆宣揚和時髦的東西，去適應這些大肆宣揚和時髦的東西。

軟件架構模式和風格

客 戶端/服務端 是由兩部分組成的軟件架構模型，通過計算機網絡——或在同一臺計算機上——相互通訊的客戶端系統和服務端系統。一個客戶端-服務端應用是由客戶端和服務端 軟件組成的分布式系統。客戶端-服務端應用提供了一種分擔負載的好方法。客戶端進程總是啟動一個到服務端的連接，而服務端進程則總是等待來自任何客戶端的 請求。客戶端-服務端架構有時也角度奧兩層架構。

基于組件的架構

基于組件的架構關注于設計的分解，即設計成單獨的功能性或邏輯性組件來表示定義明確、包含方法、事件與屬性的通信接口。它提供了更高層次的抽象并將問題分解為與組件相關的子問題。

基于組件的架構的首要目的是確保組件的復用性。組件將一個軟件元素的功能與行為封裝到一個可重用的、獨立部署的可執行單元。

下面是用UML 2.0表示的兩個組件。負責處理用戶訂單的checkout組件需要通過CardProcessing組件從用戶的信用卡/借記卡中扣費(即后者提供的功能)。

領域驅動設計

領域驅動設計(DDD)是創建滿足核心業務目標的高質量軟件的方法。它強調領域專家、開發者、UX(用戶體驗)設計師及其他相關人員間的合作，以創建一個 能反映業務需求的領域模型。這包括通用術語(也稱為通用語言)的協商、業務實體的指定及其行為與聯系，并以一種能夠生成整潔且模塊化的實現方法進行組織。

策略領域驅動設計模式及其間的關系

分層架構

分層架構專注于將應用程序中的相關功能組合到不同的層級中，層級間呈現出垂直層疊的結構。每一層中的功能都同一個通用和角色或者職責相關。層級間的通信是 明晰的，而且是松耦合的。將你的應用程序分出層級來非常有助于對關注點分離策略的支持，而這回頭就支持了靈活性和可維護性。

消息總線架構

消息總線架構描述了描述了一個使用軟件系統的原則，那就是能使用一個或者更多的通信信道來接收和發送消息，那樣應用程序無需知道每個信道的特定的細節就能 實現交互。這是一種設計應用程序的風格，采用這種風格之后應用程序間的交互就由公共總線上消息的傳遞來完成(這種傳遞經常是異步的) 。消息總線架構最常用的實現不是使用的消息路由，就是發布/訂閱模式，并且經常使用一個諸如消息隊列這樣的消息系統來實現。

N層/3層架構

N層/3層架構描述是將功能大致像分層風格的架構那樣分隔成幾段，而讓每一段都成為可以被放到一個物理上分離的計算機上的層。它們是通過面向組件的方法被發展而來的，一般通信是用的特定于平臺的方法，而不是基于消息的方式。

面向對象的架構

面向對象的架構是一種基于責任分解的設計范式，即將系統分解為獨立可復用的對象，每個對象包含了與自身相關的數 據與行為。面向對象設計將系統看作一系列相互協作的對象，而不是一組程序或處理指令。對象間相互分離、獨立且耦合松散；它們通過接口調用或處理其他對象內 的屬性，并通過消息的發送與接收在接口上進行通信。

面向服務的架構(SOA)

面向服務的架構（SOA）是一種用于創建基于服務的使用的體系結構的方法。服務(例如 RESTful Web service)實現了一些小的功能，如生成數據、驗證用戶或提供簡單的分析服務。

SOA 架構的關鍵是相互獨立且松耦合的服務間的互動。SOA 架構實現了服務的復用，因此在升級或需要做其他變動時不需要再從頭開始。

洋蔥架構

洋蔥架構是由 Jeffrey Palermo 提出的，它類似于 Alistair Cockburn 提出的六邊形架構(Hexagonal Architecture)。

該架構的提出最初是為了避免在 N 層架構中各層間的依賴關系。它通過將所有基礎服務（包括數據庫）移出問題域來實現。將此理論實施到 N 層架構意味著要將依賴流反轉，從而將業務邏輯獨立出來。

這個理論生成了一個新的模型，在這個模型中業務邏輯處于架構的中心，其他層圍繞在它周圍形成同心環，就像一個洋蔥一樣。

總結

這是第一個專注于涵蓋與軟件架構主題相關的系列文章。

我們將很快發布該系列的更多文章，敬請關注。您可以免費訂閱此博客以獲取每周更新的新文章。

參考

• https://msdn.microsoft.com/en-us/library/ee658098.aspx

• https://msdn.microsoft.com/en-us/library/ee658117.aspx

• https://en.wikipedia.org/wiki/Software_architecture

• http://sanderhoogendoorn.com/blog/index.php/why-do-we-need-software-architecture

• https://simple.wikipedia.org/wiki/Client-server

• http://www.tutorialspoint.com/software_architecture_design/component_based_architecture.htm

• https://archfirst.org/domain-driven-design

• http://www.cs.ccsu.edu/~stan/classes/CS530/Notes14/06-ArchitecturalDesign.html

• http://searchsoa.techtarget.com/definition/service-oriented-architecture

• https://blog.apnic.net/2015/08/18/architecture-at-apnic-the-onion-architecture

• http://www.slideshare.net/kindblad/application-architecture-32607528                                        

License

本文及相關源碼與文件受 MIT 協議保護。