本文打算探討一下軟件架構(gòu)設(shè)計的一些設(shè)計原則與經(jīng)過實踐驗證的設(shè)計模式。這些軟件架構(gòu)設(shè)計的原則和模式已經(jīng)有幾十年的歷史了。
軟件，應(yīng)該根據(jù)其職能分成多個層次。分層架構(gòu)設(shè)計思想，有很多成功的例子。如網(wǎng)絡(luò)設(shè)計上，OSI七層網(wǎng)絡(luò)模型，就把網(wǎng)絡(luò)應(yīng)用軟件，按照功能分成了職能各異的七個層次。實際網(wǎng)絡(luò)中使用的TCP/IP協(xié)議，也遵循OSI七層網(wǎng)絡(luò)模型，只是把OSI的應(yīng)用層，表示層和會話層全部糅合在應(yīng)用層內(nèi)而已。
可以說，按照功能進行分層，是一個經(jīng)過實踐檢驗、行之有效的軟件設(shè)計方案。
從大的范圍來分，軟件可以分為兩個層次：前端和后臺。這兩個概念大家應(yīng)該都很熟悉。很多程序員招聘廣告，都區(qū)分前端工程師和后臺工程師。
前端，也常稱為UI。是用戶界面應(yīng)用程序。用戶界面應(yīng)用程序，是直接和用戶進行交互的軟件。常見的前端應(yīng)用有：命令行程序，Web應(yīng)用，桌面應(yīng)用（包括移動設(shè)備應(yīng)用）。除了命令行程序外，都是圖形化界面。本文只介紹圖形化界面的前端程序。
前端程序，負(fù)責(zé)與用戶進行交互。負(fù)責(zé)接收和校驗用戶輸入，并向用戶反饋輸出。其業(yè)務(wù)操作是委托給后臺來實現(xiàn)的。
前端程序，必用的設(shè)計模式，是20世紀(jì)80年代發(fā)現(xiàn)的MVC模式。所有成功的前端應(yīng)用，都使用了MVC模式或者它的一些變體。
MVC模式，MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫。它是Gof設(shè)計模式一書中介紹的第一種設(shè)計模式，是設(shè)計模式之母。
MVC模式，就是用控制器來管理用戶輸入、輸出和圖形界面。數(shù)據(jù)來自模型部分。模型Model實際上集中管理了業(yè)務(wù)數(shù)據(jù)。這使對同一種業(yè)務(wù)數(shù)據(jù)展現(xiàn)多種圖形界面成為了可能。MVC模式，分離了顯示邏輯和業(yè)務(wù)邏輯。
應(yīng)用MVC模式的前端應(yīng)用中，模型Model是通向后臺系統(tǒng)的通道。
前端應(yīng)用負(fù)責(zé)提供與用戶交互的軟件。后臺則向前端提供業(yè)務(wù)服務(wù)。所有業(yè)務(wù)相關(guān)的操作和服務(wù)應(yīng)該由后臺來實現(xiàn)。
前端和后臺，可以是在同一個進程中的，也可以是分屬不同進程的。
一般，較簡單或者小型的單機系統(tǒng)，前端和后臺都在同一個進程中。也就是都屬于圖形應(yīng)用程序(或者命令行應(yīng)用程序)。這種應(yīng)用程序，前端部分代碼，通過API調(diào)用直接調(diào)用后臺提供的業(yè)務(wù)服務(wù)。如Office軟件就是單機系統(tǒng)。
復(fù)雜或者分布式系統(tǒng)，前端和后臺屬于不同的進程，前端通過進程間調(diào)用機制來調(diào)用后臺提供的業(yè)務(wù)服務(wù)接口。目前常用的進程間調(diào)用機制有：WebService、REST、基于TCP自己實現(xiàn)的通訊協(xié)議，編程語言自己定義的通訊協(xié)議，操作系統(tǒng)自己定義的通訊協(xié)議等。如，現(xiàn)在很多企業(yè)級應(yīng)用軟件，Web應(yīng)用，互聯(lián)網(wǎng)應(yīng)用等。
后臺系統(tǒng)本身，也需要分為多個層次，包括：接口層，業(yè)務(wù)層，助手層。分別對應(yīng)于大家應(yīng)該都很熟悉的JavaEE中的表現(xiàn)層，業(yè)務(wù)層，持久化層。
接口層，在JavaEE中稱為表現(xiàn)層。就是后臺系統(tǒng)對外的接口層，用于實現(xiàn)跨進程調(diào)用。接口層的代碼，和你使用的進程間調(diào)用機制有關(guān)。如，你使用WebService，那么接口層就是用來處理WebService請求的代碼；你使用Rest，那么接口層就是處理Http請求和返回Http響應(yīng)的相關(guān)代碼；你使用的是RMI這樣的語言定義的通訊協(xié)議，接口層就是用RMI協(xié)議接收和發(fā)送數(shù)據(jù)的相關(guān)代碼。
接口層，應(yīng)用了Gof設(shè)計模式中的Fa?ade門面模式。它向前端（客戶端）提供了一個簡潔一致的接口，隱藏了系統(tǒng)的復(fù)雜性。只要保證接口不變，那么后臺的業(yè)務(wù)層和助手層代碼再怎樣變化，對前端（客戶端）程序都是透明的。
JavaEE中稱之為表現(xiàn)層，意為和Web圖形界面有關(guān)。這是因為當(dāng)時JavaEE提出這種分層時，Struts等JavaWeb前端框架正大行其道。Struts等會把html頁面返回給瀏覽器，具備呈現(xiàn)圖形界面的功能。
但目前，前端和后臺完全分離的應(yīng)用很多，并已經(jīng)成為一種趨勢。如，前端是桌面應(yīng)用或者移動應(yīng)用，顯然只需要和后臺交換業(yè)務(wù)數(shù)據(jù)，不需要后臺返回圖形界面。Web開發(fā)中，目前也流行Html頁面上嵌入JavaScript代碼通過AJAX向后臺交換業(yè)務(wù)數(shù)據(jù)，而不是要求后臺返回html頁面。接口層不再需要返回html頁面，只需要返回數(shù)據(jù)。
因此這里我命名為接口層而不是表現(xiàn)層，更為貼切。
另外，對于前端和后臺在一個進程中的軟件，無需定義接口層。前端部分直接通過API調(diào)用后臺部分的業(yè)務(wù)代碼即可。
業(yè)務(wù)層，負(fù)責(zé)定義領(lǐng)域?qū)ο?，完成業(yè)務(wù)邏輯的處理。它向前臺提供后臺需要的所有服務(wù)。
每一個應(yīng)用程序，都有其需要解決的問題。針對其問題域，需要劃定問題范圍，進行數(shù)學(xué)建模，識別領(lǐng)域?qū)ο螅⒍x各個領(lǐng)域?qū)ο笾g的關(guān)系。
數(shù)學(xué)建模和識別領(lǐng)域?qū)ο蟮姆椒ㄓ卸喾N。下面分享一下我一直使用的一種方法：
1，請需求方描述清楚問題是什么，想要得到什么結(jié)果。
2，描述自己的解決方案，能夠做到什么，尋求需求方的確認(rèn)。
3，對解決方案文字化。找出其中所有名詞和動詞。名詞就是領(lǐng)域?qū)ο蟮暮蜻x對象。動詞是領(lǐng)域?qū)ο蟮姆椒ǖ暮蜻x對象。尋找名詞之間的制約關(guān)系。
4，確定領(lǐng)域?qū)ο蟮年P(guān)系。我使用關(guān)系數(shù)據(jù)庫的設(shè)計方法，確定對象之間是一對一關(guān)系，多對一關(guān)系還是多對多關(guān)系。
關(guān)系數(shù)據(jù)庫實際上和面向?qū)ο笙到y(tǒng)是完全等價的。這可以從很多O-R mapping框架上看出來。
我對關(guān)系數(shù)據(jù)庫設(shè)計非常熟悉，因此我總是使用這種方法識別和定義領(lǐng)域?qū)ο?。即使在一些?yīng)用場景中，領(lǐng)域?qū)ο蟾静恍枰志没?，我還是用這種方式來考察領(lǐng)域?qū)ο蟆?/p>
5，根據(jù)識別出的領(lǐng)域?qū)ο螅捌湎嗷ブg的關(guān)系，需要實現(xiàn)的方法，用面向?qū)ο蟮乃季S編碼。用面向?qū)ο蟮乃季S編碼，不意味著必須使用類。用C這樣的過程式編程語言也可以用面向?qū)ο蟮乃季S編碼。只是你心中要放著對象這個概念即可。如，我用Python編碼時，很少使用類，經(jīng)常是直接使用函數(shù)。但心中還是存著“對象”的理念的，這樣寫出的代碼才不會亂。
業(yè)務(wù)層代碼，會需要使用一些第三方軟件提供的服務(wù)或者其他更低層級的自己開發(fā)的軟件服務(wù)，才能實現(xiàn)其業(yè)務(wù)邏輯。這些不屬于接口層，也不屬于業(yè)務(wù)層的代碼，我們稱其屬于助手層。助手層代碼是為了協(xié)助業(yè)務(wù)層代碼實現(xiàn)功能而存在的。
助手層，在JavaEE中稱為持久化層。因為JavaEE是一個企業(yè)級軟件架構(gòu)設(shè)計方案。其針對的是企業(yè)的信息系統(tǒng)。其業(yè)務(wù)邏輯一般就是操作數(shù)據(jù)庫。
數(shù)據(jù)庫的讀寫訪問，是與具體業(yè)務(wù)邏輯無關(guān)的，是幫助實現(xiàn)業(yè)務(wù)邏輯的。因此JavaEE稱為持久化層。但這個定義也不全面。因為還是存在很多系統(tǒng)，其除了訪問數(shù)據(jù)庫外，還需要其他服務(wù)才能實現(xiàn)業(yè)務(wù)邏輯。如，一個視頻網(wǎng)站，它可能需要對上傳的視頻文件進行格式轉(zhuǎn)換，進行文件切分等；OpenStack，除了訪問數(shù)據(jù)庫，還需要訪問各個Hypervisor的管理軟件來管理虛擬機，需要訪問網(wǎng)絡(luò)部分代碼，管理虛擬網(wǎng)絡(luò)，需要訪問存儲部分代碼，訪問塊設(shè)備和文件等。
因此，我認(rèn)為稱之為助手層比持久化層更具普適性。
假設(shè)我們的應(yīng)用是一個類似美團這樣的優(yōu)惠券應(yīng)用，需要操作地圖的功能。對優(yōu)惠券應(yīng)用來說，自己的領(lǐng)域?qū)ο蟀ㄉ虘?、?yōu)惠券、用戶等。操作地圖的功能，不屬于領(lǐng)域?qū)ο?，也就不屬于業(yè)務(wù)層的范圍。它是為服務(wù)層服務(wù)的。因此操作地圖的功能，在優(yōu)惠券應(yīng)用中就屬于助手層。助手層使用的地圖API，實際上可能是調(diào)用百度地圖服務(wù)。
對于百度地圖服務(wù)來說，它相當(dāng)于一個后端系統(tǒng)，其也由接口層、服務(wù)層和助手層構(gòu)成。地圖的位置信息、興趣點等是它的服務(wù)。
因此，服務(wù)層和助手層的區(qū)別，實際上是邏輯概念上的區(qū)別。一個系統(tǒng)的服務(wù)層，對于其他系統(tǒng)可能就是助手層。
比如，一個企業(yè)信息化應(yīng)用，需要處理一些時間、字符串、集合等相關(guān)的函數(shù)。這些函數(shù)在這個應(yīng)用中就屬于助手層。因為時間，字符串，集合都屬于我的系統(tǒng)的領(lǐng)域?qū)ο?，它們是為業(yè)務(wù)服務(wù)的。是更低一個層級的。
總之，后臺部分中，不屬于接口層和業(yè)務(wù)層的所有代碼，都屬于助手層。
我們以openstack為例具體說明業(yè)務(wù)層和助手層的區(qū)別。
openstack的業(yè)務(wù)層，包括其定義的server，也就是虛擬機。
而虛擬機的業(yè)務(wù)邏輯代碼，需要調(diào)用hypervisor 管理工具。如果使用KVM這個hypervisor，就需要使用libvirt的客戶端庫。libvirt客戶端在openstack中就是助手層代碼。
而libvirt客戶端庫又會通過網(wǎng)絡(luò)調(diào)用libvirt后臺。在libvirt后臺系統(tǒng)中，也包括了接口層，業(yè)務(wù)層，助手層這樣的層次。
libvirt內(nèi)部定義了虛擬機這樣的領(lǐng)域?qū)ο?，對其的操作，需要使用qemu命令行程序。qemu命令行程序在libvirt中就屬于助手層。
這就像是剝洋蔥，剝開一層里面還有一層。你在剝哪層，哪層就是業(yè)務(wù)層，其內(nèi)部的層次就屬于助手層。
讓我們上升到哲學(xué)的高度。這種分層的研究方法，就是形而上學(xué)的方法，是用孤立、靜止、片面的觀點觀察和研究世界的思維方式。一次聚焦和處理軟件系統(tǒng)的一個層面的邏輯。不采用這種方法，眉毛胡子一把抓是做不好軟件的。
分層的軟件設(shè)計思想已經(jīng)存在很多個年頭了，在計算機科學(xué)的各個領(lǐng)域都證明了它的成功。前端（MVC模式）和后端（接口層-業(yè)務(wù)層-助手層）的分層設(shè)計也經(jīng)過了幾十年大量軟件的證明。
分層的思想，就是每一個層次專注做一件事情。每一個層次都為上層提供服務(wù)。每一個層次對于其上層來說，都是可以復(fù)用的。
如，助手層的代碼，時間、字符串等函數(shù)，換一個應(yīng)用也可以用上。后端部分，可以為多個前端應(yīng)用提供服務(wù)。前端一開始可能是桌面應(yīng)用，后面變成Web應(yīng)用，之后可能再開發(fā)移動應(yīng)用，后端都不需要改變。一個框架的服務(wù)層代碼，在另一個應(yīng)用中，可以成為助手層代碼。一個應(yīng)用的整個后臺，也可能成為另一個應(yīng)用的助手層。
分層設(shè)計的軟件，結(jié)構(gòu)清晰，代碼各司其職，能夠最大限度地重用代碼。
PS：后面打算再找時間談一下海量規(guī)模的軟件架構(gòu)的設(shè)計原則和模式。
