架構是什麼

架構亂像

前幾年換工作的時候，見到一件著名IT公司CTO準備把架構師這個崗位取消。一時之間頗為感慨——架構師這個崗位不知道什麼時候產生的，但00年後非常盛行，不少歐美有一點技術背景的CEO紛紛在名片上寫首席架構師，西風東漸，綿延至今神州大地已是遍地架構師。一個笑話說：西溪園區十個磚頭丟下去，至少砸死5個高P，3個架構師。也不少人笑談所謂架構師已成周報彙集器，PPT製造者，初入職場的程式設計師往往會在知乎問：架構師寫程式碼麼？架構師每天應該分配多少精力寫程式碼？架構師應該幹什麼？ 即使是已經幹了七八十來年的所謂老鳥，也往往困惑架構師是什麼。現實中，架構師的確各式各樣人等都有，往往是做的久了，或者業績好了就是；授予這個title的所謂評委們往往也是如此而來，大家都是稀裡糊塗的做著自以為是的架構師。其中混子也越來越多，於是難怪有些人憤憤然要取消這個title。然而取消就能解決問題麼？

正確的做法不是掩耳盜鈴，而是正本清源。

架構的必要性

架構因複雜性而生。

複雜性因軟體本質而生。

《人月神話-軟體的根本困難》中說

軟體的本質

和語言實現無瓜、和類庫元件無關……

是

一些

概念、概念之間的關係、以及不確定性

。這個本質的結構事實上類似於我們中學物理學到過的鏈式反應——原子、中子、以及裂變。由此我們可以想象軟體工程的困難所在——正如brooks的人月定律所描述的——當一個軟體專案陷入焦油坑的時候加人解決不了問題、減人解決不了問題、減需求解決不了問題、加需求也解決不了問題、降低質量要求解決不了問題、提升質量要求一樣解決不了問題……只要有變化發生，對軟體體系就產生難以預測的影響，這個時候陷入焦油坑的軟體本質上已經陷入一個“混沌”系統，不確定哪一個外部變化是蝴蝶的翅膀。

複雜性是架構設計的前提。

架構是什麼

大型複雜專案，一個顯著的特徵就是人多。如果沒有架構，一擁而上，別說戰鬥力，彼此之間的協調都很難保證，“巴別塔”工作量是有限的，勞動力和資源供應充足，為什麼永遠建不成？

從結果上看：透過一定的設計，將複雜性向大部分團隊成員遮蔽、呈現簡單可靠的擴充套件介面，使得團隊可以發揮人

多力量大

的優勢、而架構本身又必須確保

抽象契合領域

本身規律，使得業務能自由而快速的表達，具有極高的擴充套件性、靈活性、可靠性……

如何做到呢？

架構還有一種比較標準的定義：（wiki）

軟體架構

是有關軟體整體

結構

與

元件

的抽象描述，用於指導大型軟體系統各個方面的設計。軟體架構會包括軟體元件、元件之間的關係，元件特性以及元件間關係的特性［1］。軟體架構可以和建築物的架構相比擬［2］。

在這種思路中，建議構建業務的最好方式是使用盡可能現成的元件，好比蓋一個房子，不是自己從沙子起進行底層原子結合力、分子結合力、彙編原理……開始研究而是應該儘可能使用現成的元件。（參見附錄#1）

但是如何做呢？這種

元件架構只是說明一個狀態，既交代不清楚原因，也說不清楚如何去做

。領域驅動理論可以可以彌補這個缺陷。

邏輯上治理複雜度的治理方式有三種水平、垂直切割複雜度，以及抽象

領域驅動將這三者完美融合在一起。

複雜度治理方式

對應概念

具體做法

水平劃分

領域驅動

劃分業務層/領域層/技術層

兩側依賴中間，中間優先兩側、驅動業務實現和技術實現。

垂直劃分

領域

同一層次中，可依據內聚性劃分為不同的模組。

抽象

領域驅動

業務層完整的包含

業務層：業務具體實現領域層：業務抽象前者是後者介面的簡單擴充套件，後者將前者的複雜性和耦合性封裝。

然而領域驅動其實存在一些問題

1，是否任何問題域都存在可抽象的領域

2，如果不是，那麼如何區分

這個問題不能解決，就一定會在如何使用領域上浪費時間、或者無所適從。譬如，日常開發的業務系統存在領域麼？如果存在，可以進行領域驅動設計麼？如果可以，應該如何做呢？

領域驅動理論沒有解決這個問題，但是基於拓撲風格的容器-元件JEE體系卻無意中解決了這個問題——如果存在，那麼成為元件；即使不存在，依然可以納入容器之中沉澱為元件。

至此，軟體架構理論在整體上已經是比較完備的了。僅僅還有一個細節：元件內部構造應該是什麼樣子的？

領域驅動的程式碼角色模型解決了這個問題。

對於任何一個功能，僅且僅存在如下四種資料、邏輯組成的物件

資料

邏輯

物件概念

對應設計概念

請求資料

處理請求的邏輯

時序物件（聚合根）

UML時序主圖

實體資料

處理實體資料的邏輯

實體物件

時序圖中的生命線物件

變化資料

處理變化的邏輯

值物件

物件圖中的實現/整合關係。

以上的關係資料

以上綜合邏輯

上下文

#

結合領域本身的概念。

資料

邏輯

物件概念

對應設計概念

領域物件

領域邏輯

領域物件

介面

防腐層

防腐層

對於每一種物件概念，其都是資料+邏輯組成的整體概念，在實現上不必一定是一個class——當然如果是會比較優雅。在這種理論指導之下，那麼如何寫程式碼也基本上是一件模式化的工作。

最近100年以來，數學已經開始發展到了邏輯上“確定性的喪失”，物理學理論已經探究到自然的“不確定性本質”，最近50年以來，人類越來越開始關注“渦流”、“混沌”等現象，新老三論已經有了一些結論，而最近流行的複雜系統科學，同樣研究物件是複雜系統。這正是軟體系統本質的特徵。

不僅僅是物理和數學，即使是生物演化理論和和計算機行業結合起來。如果我們瞭解基因科學的化，我們就往往能夠了解基因科學和計算機科學的驚人相似性：ACTG = 四進位制程式設計。大自然在億萬斯年中以此構造出了生物程式：

基因決定器官

（程式）。而領域驅動中提出了一種非常重要的概念“聚合根”——想象任何一個請求的對應的程式的處理結構，都像一個魚刺狀結構，任何一個魚刺的脈絡都和請求物件某個屬性密切相關。這相當於是在說：

資訊決定了架構

。

資訊是什麼？是確定性的增加，那麼架構是什麼就很明顯了。架構就是具體確定性，可靠性，可能性空間……的適應性系統

架構的歷史

軟體的歷史上，複雜性並不是第一齣現。自軟體行業誕生以來，產生了4次軟體危機

軟體危機

解決方案

解決的問題

典型軟體

工程管理

第一次1950~1970

結構化程式設計

1，客戶從政府國防部轉變為大企業、院校2，任務管理從人工排隊轉向作業系統排程3，機型從數種變為數十種4，從業人員膨脹到近萬

OS360UNIX

無

第二次1980~2000

面嚮物件語言

模組化

1，客戶從大企業變成個人2，OS轉向圖形化、應用軟體數量和體積急劇膨脹3，裝置從數百/千種膨脹為數千4，從業人員從數萬膨脹為數十萬

WINDOWSLOTUS紅警AUTOCAD

瀑布

第三次2005~2015

SOA

1，企業開始全面資訊化2，軟體複雜度是多樣性的客戶需求3，軟體體系從單一方案轉向靈活組合，走向分散式 #144，從業人員從數十萬膨脹到數百萬

SAP亞馬遜

淘寶支付寶

瀑布敏捷

第四次2015~

雲、微服務、中臺？

1，社會全面資訊化 #212，軟體更小、型別更多、彼此整合度更高、3，更貼近業務側，業務資訊密度更高4，從業人員從數百萬膨脹到千萬

雲平臺

Netflix Facebook

瀑布敏捷

綜合多次軟體危機的相同點，可以發現一些規律

1，行業的發展導致軟體的需求複雜度和規模急劇上升

2，生產力提升主要透過從業規模來解決

3，需要有簡單的工具/架構元件，讓大規模團隊協作不容易出錯

4，架構元件開始越來越接近業務側

5，架構元件的粒度開始更粗粒度、更大尺寸

當前的問題

軟體發展的每個時代，有每個時代的困難。我們今天中國軟體架構方面最大的難題就是中臺。

1960年前後的時候，市場需要比彙編更友好的語言來支撐龐大的開發團隊和市場。80年代的時候，市場需要比結構化程式語言更健壯有效的工具來支撐更龐大的團隊和市場。00年後，市場需要更加碎片化、但是組合更靈活的架構來適應新的靈活多變的市場。

今天，我們的架構挑戰即是新時代市場的要求，和以往有所不同

1，資訊科技已經從簡單的ERP，OA走向社會的方方面面，從打車到吃飯，從個人到企業、政府

2，每一個領域的業務多樣化都無比繁多和複雜

3，更貼近業務側而不是技術側

中國式的軟體同歐美的軟體不同

1，由於人數比較龐大，中國軟體對效能的要求往往比較高

2，功能靈活，要求能根據各種情況靈活調整

3，因此也對審批、管理的要求比較高，更靈活也更嚴格

……

這也決定了中國軟體行業率先碰到新時代的軟體危機。2000年，當競爭對手還在走研發審批流程的時候（希望的審批還算是少），淘寶已經上線了。馬雲得意的說是對手自己打敗了自己。2015年當他從superccell參觀回來，我想他似乎已經看到阿里已經變成了2000死去的對手——阿里開始轟轟烈烈做起了中臺。

以往，所有的架構挑戰，往往都是純粹技術的。這一次，軟體已經和社會結合的如此緊密，他不僅僅是技術本身的問題。不過，阿里的第一次挑戰以失敗而告終。但是更多的公司在繼續，我看到有不少的公司已經有了一些成果，比如滴滴對核心系統成功重構的灣流專案。——不過我認為這個專案既成功又失敗，成功是因為這個專案本身是成功的，失敗是因為這個專案本身並不會對任何其他領域有太多直接的幫助。阿里的失敗呢，可以說是既失敗也成功，失敗呢是因為核心的業務中臺失敗了，成功是除此以外資料中臺、技術中臺等都成功過了——這決定了阿里可以對外進行技術輸出，但很難對對方提供更有價值的業務解決方案。

但反觀歐美，則這種情況並不明顯。他們的網際網路業務既沒有這麼繁雜，也沒有如此各種靈活的要求，但畢竟中國已經走到了軟體複雜度膨脹的瓶頸上了。只不過這一次，突破瓶頸的架構答案必須我們自己去探尋。

在唐則詩，在宋則詞，一代人有一代人的使命。今日之困難，當今人畢之

附錄

#1：在《系統架構》一書中建議使用的原則是“進2退1”