1. 軟件項目的套路

如果你平時的工作是做各種項目(而不是產(chǎn)品)，而且你工作的時間足夠長，那么自然見識過很多不同類型的項目。在切換過多次上下文之后，作為程序員的你，自然而然的會感到一定程度的重復(fù)，稍加抽象，你會發(fā)現(xiàn)所有的業(yè)務(wù)系統(tǒng)都幾乎做著同樣的事情：

• 從某種渠道與用戶交互，從而接受輸入(Native App，Mobile Site，Web Site，桌面應(yīng)用等等)
• 將用戶輸入的數(shù)據(jù)按照一定規(guī)則進行轉(zhuǎn)換，然后保存起來(通常是關(guān)系型數(shù)據(jù)庫)
• 將業(yè)務(wù)數(shù)據(jù)以某種形式展現(xiàn)(列表，卡片，地圖上的Marker，時間線等)

稍加簡化，你會發(fā)現(xiàn)大部分業(yè)務(wù)系統(tǒng)其實就是對某種形式的資源進行管理。所謂管理，也無非是增刪查改(CRUD)操作。比如知乎是對“問題”這種資源的管理，LinkedIn是對“Profile”的管理，Jenkins對構(gòu)建任務(wù)的管理等等，粗略的看起來都是這一個套路(當(dāng)然，每個系統(tǒng)管理的資源類型可能不止一種，比如知乎還有時間線，Live，動態(tài)等等資源的管理)。

這些情況甚至?xí)o開發(fā)者一種錯覺：世界上所有的信息管理系統(tǒng)都是一樣的，不同的僅僅是技術(shù)棧和操作的業(yè)務(wù)對象而已。如果寫好一個模板，幾乎都可以將開發(fā)過程自動化起來。事實上，有一些工具已經(jīng)支持通過配置文件(比如yaml或者json/XML)的描述來生成對應(yīng)的代碼的功能。

[[193288]]

如果真是這樣的話，軟件開發(fā)就簡單多了，只需要知道客戶業(yè)務(wù)的資源，然后寫寫配置文件，***執(zhí)行了一個命令來生成應(yīng)用程序就好了。不過如果你和我一樣生活在現(xiàn)實世界的話，還是趁早放棄這種完全自動化的想法吧。

2. 復(fù)雜的業(yè)務(wù)

現(xiàn)實世界的軟件開發(fā)是復(fù)雜的，復(fù)雜性并不體現(xiàn)在具體的技術(shù)棧上。如Java，Spring，Docker，MySQL等等具體的技術(shù)是可以學(xué)習(xí)很快就熟練掌握的。軟件真正復(fù)雜的部分，往往是業(yè)務(wù)本身，比如航空公司的超售策略，在超售之后Remove乘客的策略等;比如亞馬遜的打折策略，物流策略等。

用軟件模型如何優(yōu)雅而合理的反應(yīng)復(fù)雜的業(yè)務(wù)(以便在未來業(yè)務(wù)發(fā)生變化時可以更快速，更低錯誤的作出響應(yīng))本身也是復(fù)雜的。要將復(fù)雜的業(yè)務(wù)規(guī)則轉(zhuǎn)換成軟件模型是軟件活動中非常重要的一環(huán)，也是信息傳遞往往會失真的一環(huán)。業(yè)務(wù)人員說的A可能被軟件開發(fā)者理解成Z，反過來也一樣。

舉個例子，我給租來的房子買了1年的聯(lián)通寬帶?？墒沁^了6個月后，房東想要賣房子把我趕了出來，在搬家之后，我需要通知聯(lián)通公司幫我做移機服務(wù)。

如果純粹從開發(fā)者的角度出發(fā)，寫出來的代碼可能看起來是這樣的：

public class Customer { 
  private String address; 
 
  public void setAddress(String address) { 
    this.address = address; 
  } 
      
  public String getAddress() { 
    return this.address; 
  } 
} 

中規(guī)中矩，一個簡單的值對象。作為對比，通過與領(lǐng)域?qū)＜业慕涣髦?，寫出來的代碼會是這樣：

public class Customer { 
  private String address; 
 
    public void movingHome(String address) { 
    this.address = address; 
  } 
} 

通過引入業(yè)務(wù)場景中的概念movingHome，代碼就變得有了業(yè)務(wù)含義，除了可讀性變強之外，這樣的代碼也便于和領(lǐng)域?qū)＜疫M行交流和討論。Eric在領(lǐng)域驅(qū)動設(shè)計(Domain Drvien Design)中將統(tǒng)一語言視為實施DDD的先決條件。

3. 層次架構(gòu)(三明治)

All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections.

-- David Wheeler

上文提到，業(yè)務(wù)系統(tǒng)對外的呈現(xiàn)是對某種資源的管理，而且，現(xiàn)實世界里的業(yè)務(wù)系統(tǒng)往往要對多種資源進行管理。這些資源還會互相引用，互相交織。比如一個看板系統(tǒng)中的泳道、價值流、卡片等;LinkedIn中的公司，學(xué)校，個人，研究機構(gòu)，項目，項目成員等，它們往往會有嵌套、依賴等關(guān)系。

為了管理龐大的資源種類和繁復(fù)的引用關(guān)系，人們自然而然的將做同樣事情的代碼放在了統(tǒng)一的地方。將不同職責(zé)的事物分類是人類在處理復(fù)雜問題時自然使用的一種方式，將復(fù)雜的、龐大的問題分解、降級成可以解決的問題，然后分而治之。

(圖片來自：http://t.cn/RSNienv)

比如在實踐中 ，展現(xiàn)部分的代碼只負責(zé)將數(shù)據(jù)渲染出來，應(yīng)用部分的代碼只負責(zé)序列化/反序列化、組織并協(xié)調(diào)對業(yè)務(wù)服務(wù)的調(diào)用，數(shù)據(jù)訪問層則負責(zé)屏蔽底層關(guān)系型數(shù)據(jù)庫的差異，為上層提供數(shù)據(jù)。

這就是層級架構(gòu)的由來：上層的代碼直接依賴于臨近的下層，一般不對間接的下層產(chǎn)生依賴，層次之間通過精心設(shè)計的API來通信(依賴通常也是單向的)。

以現(xiàn)代的眼光來看，層次架構(gòu)的出現(xiàn)似乎理所應(yīng)當(dāng)、自然而然，其實它也是經(jīng)過了很多次的演進而來的。以JavaEE世界為例，早期人們會把應(yīng)用程序中負責(zé)請求處理、文件IO、業(yè)務(wù)邏輯、結(jié)果生成都放在servlet中;后來發(fā)明了可以被Web容器翻譯成servlet的JSP，這樣數(shù)據(jù)和展現(xiàn)可以得到比較好的分離(當(dāng)然中間還有一些迂回，比如JSTL、taglib的濫用又導(dǎo)致很多邏輯被泄露到了展現(xiàn)層);數(shù)據(jù)存儲則從JDBC演化到了各種ORM框架，***再到JPA的大一統(tǒng)。

如果現(xiàn)在把一個Spring-Boot寫的RESTful后端，和SSH(Spring-Struts-Hibernate)流行的年代的后端來做對比，除了代碼量上會少很多以外，層次結(jié)構(gòu)上基本上并無太大區(qū)別。不過當(dāng)年在SSH中復(fù)雜的配置，比如大量的XML變成了代碼中的注解，容器被內(nèi)置到應(yīng)用中，一些配置演變成了慣例，大致來看，應(yīng)用的層次基本還是保留了：

• 展現(xiàn)層
• 應(yīng)用層
• 數(shù)據(jù)訪問層

在有些場景下，應(yīng)用層內(nèi)還可能劃分出一個服務(wù)層。

4. 前后端分離

隨著智能設(shè)備的大爆發(fā)，移動端變成了展現(xiàn)層的主力，如何讓應(yīng)用程序很容易的適配新的展現(xiàn)層變成了新的挑戰(zhàn)。這個新的挑戰(zhàn)驅(qū)動出了前后端分離方式，即后端只提供數(shù)據(jù)(JSON或者XML)，前端應(yīng)用來展現(xiàn)這些數(shù)據(jù)。甚至很多時候，前端會成為一個獨立的應(yīng)用程序，有自己的MVC/MVP，只需要有一個HTTP后端就可以獨立工作。

前后端分離可以很好的解決多端消費者的問題，后端應(yīng)用現(xiàn)在不區(qū)分前端的消費者到底是誰，它既可以是通過4G網(wǎng)絡(luò)連接的iOS上的Native App，也可以是iMac桌面上的Chrome瀏覽器，還可以是Android上的獵豹瀏覽器。甚至它還可以是另一個后臺的應(yīng)用程序：總之，只要可以消費HTTP協(xié)議的文本就可以了!

這不得不說是一個非常大的進步，一旦后端應(yīng)用基本穩(wěn)定，頻繁改變的用戶界面不會影響后端的發(fā)布計劃，手機用戶的體驗改進也與后端的API設(shè)計沒有任何關(guān)系，似乎一切都變的美好起來了。

5. 業(yè)務(wù)與基礎(chǔ)設(shè)施分離

不過，如果有一個消費者(一個業(yè)務(wù)系統(tǒng))，它根本不使用HTTP協(xié)議怎么辦?比如使用消息隊列，或者自定義的Socket協(xié)議來進行通信，應(yīng)用程序如何處理這種場景? 這種情況就好比你看到了這樣一個函數(shù)：

httpService(request, response); 

作為程序員，自然會做一次抽象，將協(xié)議作為參數(shù)傳入：

service(request, response, protocol); 

更進一步，protocol可以在service之外構(gòu)造，并注入到應(yīng)用中，這樣代碼就可以適配很多種協(xié)議(比如消息隊列，或者其他自定義的Socket協(xié)議)。 比如：

public interface Protocol { 
  void transform(Request request, Response response); 
} 
 
public class HTTP implements Protocol { 
} 
 
public class MyProtocol implements Protocol { 
} 
 
public class Service {   
  public Service(Protocol protocol) { 
    this.protocol = protocol;    
  }         
    
  public void service(request, response) { 
    //business logic here 
    protocol.transfrom(request, response);   
  } 
} 

類似的，對于數(shù)據(jù)的持久化，也可以使用同樣的原則。對于代碼中諸如這樣的代碼：

persisteToDatabase(data); 

在修改之后會變成：

persistenceTo(data, repository); 

應(yīng)用依賴倒置原則，我們會寫出這樣的形式：

public class DomainService { 
  public BusinessLogic(Repository repository) { 
    this.repository = repository 
  } 
      
    public void perform() { 
      //perform business logic 
      repository.save(record); 
  } 
} 

對于Repository可能會有多種實現(xiàn)。根據(jù)不同的需求，我們可以自由的在各種實現(xiàn)中切換：

public class InMemoryRepository implements Repository {} 
public class RDBMSRepository implements Repository {} 

這樣業(yè)務(wù)邏輯和外圍的傳輸協(xié)議、持久化機制、安全、審計等等都隔離開來了，應(yīng)用程序不再依賴具體的傳輸細節(jié)，持久化細節(jié)，這些具體的實現(xiàn)細節(jié)反過來會依賴于應(yīng)用程序。

通過將傳統(tǒng)內(nèi)置在層次架構(gòu)中的數(shù)據(jù)庫訪問層、通信機制等部分的剝離，應(yīng)用程序可以簡單的分為內(nèi)部和外部兩大部分。內(nèi)部是業(yè)務(wù)的核心，也就是DDD(Domain Driven Design)中強調(diào)的領(lǐng)域模型(其中包含領(lǐng)域服務(wù)，對業(yè)務(wù)概念的建立的模型等);外部則是類似RESTful API，SOAP，AMQP，或者數(shù)據(jù)庫，內(nèi)存，文件系統(tǒng)，以及自動化測試。

這種架構(gòu)風(fēng)格被稱為六邊形架構(gòu)，也叫端口適配器架構(gòu)。

6. 六邊形架構(gòu)(端口適配器)

六邊形架構(gòu)最早由Alistair Cockburn提出。在DDD社區(qū)得到了發(fā)展和推廣，然后IDDD(《實現(xiàn)領(lǐng)域驅(qū)動設(shè)計》)一書中，作者進行了比較深入的討論。

(圖片來自：slideshare.net )

簡而言之，在六邊形架構(gòu)風(fēng)格中，應(yīng)用程序的內(nèi)部(中間的橙色六邊形)包含業(yè)務(wù)規(guī)則，基于業(yè)務(wù)規(guī)則的計算，領(lǐng)域?qū)ο?，領(lǐng)域事件等。這部分是企業(yè)應(yīng)用的核心：比如在線商店里什么樣的商品可以打折，對那種類型的用戶進行80%的折扣;取消一個正在執(zhí)行的流水線會需要發(fā)生什么動作，刪除一個已經(jīng)被別的Job依賴的Stage又應(yīng)該如何處理。

而外部的，也是我們平時最熟悉的諸如REST，SOAP，NoSQL，SQL，Message Queue等，都通過一個端口接入，然后在內(nèi)外之間有一個適配器組成的層，它負責(zé)將不同端口來的數(shù)據(jù)進行轉(zhuǎn)換，翻譯成領(lǐng)域內(nèi)部可以識別的概念(領(lǐng)域?qū)ο?，領(lǐng)域事件等)。

內(nèi)部不關(guān)心數(shù)據(jù)從何而來，不關(guān)心數(shù)據(jù)如何存儲，不關(guān)心輸出時JSON還是XML，事實上它對調(diào)用者一無所知，它可以處理的數(shù)據(jù)已經(jīng)是經(jīng)過適配器轉(zhuǎn)換過的領(lǐng)域?qū)ο罅恕?/p>

六邊形架構(gòu)的優(yōu)點：

• 業(yè)務(wù)領(lǐng)域的邊界更加清晰
• 更好的可擴展性
• 對測試的友好支持
• 更容易實施DDD

要新添加一種數(shù)據(jù)庫的支持，或者需要將RESTful的應(yīng)用擴展為支持SOAP，我們只需要定義一組端口-適配器即可，對于業(yè)務(wù)邏輯部分無需觸碰，而且對既有的端口-適配器也不會有影響。

由于業(yè)務(wù)之外的一切都屬于外圍，所以應(yīng)用程序是真的跑在了Web容器中還是一個Java進程中其實是無所謂的，這時候自動化測試會容易很多，因為測試的重點：業(yè)務(wù)邏輯和復(fù)雜的計算都是簡單對象，也無需容器，數(shù)據(jù)庫之類的環(huán)境問題，單元級別的測試就可以覆蓋大部分的業(yè)務(wù)場景。

這種架構(gòu)模式甚至可能影響到團隊的組成，對業(yè)務(wù)有深入理解的業(yè)務(wù)專家和技術(shù)專家一起來完成核心業(yè)務(wù)領(lǐng)域的建模及編碼，而外圍的則可以交給新人或者干脆外包出去。

在很多情況下，從開發(fā)者的角度進行的假設(shè)都會在事后被證明是錯誤的。人們在預(yù)測軟件未來演進方向時往往會做很多錯誤的決定。比如對關(guān)系型數(shù)據(jù)庫的選用，對前端框架的選用，對中間件的選用等等，六邊形架構(gòu)可以很好的幫助我們避免這一點。

7. 小結(jié)

軟件的核心復(fù)雜度在于業(yè)務(wù)本身，我們需要對業(yè)務(wù)本身非常熟悉才可能正確的為業(yè)務(wù)建模。通過統(tǒng)一的語言我們可以編寫出表意而且易于和業(yè)務(wù)人員交流的模型。

另一方面模型應(yīng)該盡可能的和基礎(chǔ)設(shè)施(比如JSON/XML的，數(shù)據(jù)庫存儲，通信機制等)分離開。這樣一來可以很容易用mock的方式來解耦模型和基礎(chǔ)設(shè)施，從而更容易測試和修改，二來我們的領(lǐng)域模型也更獨立，更精簡，在適應(yīng)新的需求時修改也會更容易。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文