任何在 IT 公司工作的人，對于“架構(gòu)”這個詞應(yīng)該都不陌生。但你去問“架構(gòu)”這個詞是什么意思，似乎又有點只可意會不可言傳的意思。那么

• “架構(gòu)”這個詞，它應(yīng)該如何定義呢？
• 架構(gòu)設(shè)計對于軟件系統(tǒng)和軟件開發(fā)而言起到的作用是什么呢？
• 軟件系統(tǒng)或軟件產(chǎn)品的架構(gòu)應(yīng)該用什么樣的方式表達(dá)呢？

這篇文章，會嘗試討論一下上面這些問題。

如何定義架構(gòu)設(shè)計？

我們先來看一個古老的的思想實驗：

忒休斯之船（The Ship of Theseus）最早出自羅馬帝國時代普魯塔克的記載。它描述的是一艘可以在海上航行幾百年的船，歸功于不間斷的維修和替換部件。只要一塊木板腐爛了，它就會被替換掉，以此類推，直到所有的功能部件都不是最開始的那些了。問題是，最終產(chǎn)生的這艘船是原來的那艘忒休斯之船，還是一艘完全不同的船？如果不是原來的船，那么在什么時候它不再是原來的船了？
（摘自百度百科）

哲學(xué)家們?yōu)榱诉@個問題爭論不休，而它也被稱為“忒休斯悖論”?！斑菟广Ｕ摗睂嶋H上問的是，一個物體是不是等于組成它的各個部分的總和？如果答案是肯定的，那么當(dāng)船上所有木板都被更新了，那么這條船當(dāng)然是一艘完全不同的船了。但是，直覺告訴我們，這條船還是原來的那條船啊。如果不是這樣，一所學(xué)校，學(xué)生幾年就全換一遍，老師幾十年全換一遍，難道這所學(xué)校就是一所新的學(xué)校了？一條河，河里的水奔流不息，難道這條河就不是原來那條河了？也就是說，我們憑直覺知道，一個物體并不等于組成他的各個部分的簡單加總。那么，它到底等于什么呢？

要回答這個問題，就需要引入系統(tǒng)論的觀點了。科學(xué)研究的主要方法，是把復(fù)雜事物拆解成一個個簡單模塊來分析，這種思維模式叫做“還原論”。然而，人們發(fā)現(xiàn)，還原論可以很好地解決單個事物的問題，卻很難解決系統(tǒng)性、結(jié)構(gòu)性的問題。想要解決這些復(fù)雜問題，必須重新回到“整體論”，而系統(tǒng)論正是研究這一領(lǐng)域的學(xué)科。

在《系統(tǒng)之美》這本書中，“系統(tǒng)”不是一堆事物的簡單集合，而是由一組相互連接的要素構(gòu)成的、能夠?qū)崿F(xiàn)某個目標(biāo)的整體。任何一個系統(tǒng)都由要素、連接和功能（目標(biāo)）構(gòu)成。譬如對于忒休斯之船，其要素是一堆木板，連接是這些木板的位置和鉚合關(guān)系即結(jié)構(gòu)，而功能就是航行。系統(tǒng)論講的是廣義上的系統(tǒng)，房間的溫度、公司的經(jīng)營、國家的經(jīng)濟(jì)，都可以用系統(tǒng)論的模型去進(jìn)行描述。

軟件系統(tǒng)，也是一種系統(tǒng)，因此也可以用系統(tǒng)論的方法進(jìn)行描述。架構(gòu)就是構(gòu)成軟件系統(tǒng)的要素、連接和目標(biāo)。架構(gòu)設(shè)計就是找到軟件系統(tǒng)中的要素，并將要素之間的連接描繪清楚，從而實現(xiàn)軟件系統(tǒng)目標(biāo)的過程。

為什么架構(gòu)這么重要？

架構(gòu)清晰，才能理解問題

《系統(tǒng)之美》的作者說，當(dāng)我們看一個系統(tǒng)時，往往只會注意到系統(tǒng)的要素，而忽略掉系統(tǒng)的連接和目標(biāo)。但對于一個系統(tǒng)而言，要素往往不是最重要、隨時可以替換的。如果改變了系統(tǒng)的連接，那么系統(tǒng)就會發(fā)生巨大的變化。譬如在大學(xué)里，如果不是教授給學(xué)生打分，而是學(xué)生給教授打分，那么大學(xué)就不再是大學(xué)而是商業(yè)培訓(xùn)機構(gòu)。而比連接更重要的是目標(biāo)，譬如大學(xué)的目標(biāo)如果不是教書育人，而是賺錢盈利，大學(xué)也會成為另外一種系統(tǒng)。

軟件系統(tǒng)是一種非常抽象和復(fù)雜的系統(tǒng)，軟件系統(tǒng)的構(gòu)造是一個非常復(fù)雜的問題。普通人去理解軟件系統(tǒng)往往只能看到其中的要素（功能模塊），而看不到要素之間的連接（模塊之間的關(guān)系），但如果不能確定功能模塊之間的關(guān)系而直接進(jìn)入到開發(fā)狀態(tài)，由多人或多個組織單元從事的軟件系統(tǒng)的開發(fā)就會陷入混亂，在耗費大量的人力物力和時間成本后，發(fā)現(xiàn)難以達(dá)成想要的目標(biāo)，只留了一堆需要繼續(xù)投入人力成本維護(hù)的代碼。

架構(gòu)合理，才能應(yīng)對變化

《人月神話》中有一句名言：軟件開發(fā)過程中，唯一不變的就是變化本身。變化就會帶來軟件系統(tǒng)的熵增，即軟件的生命力從最初的理想狀態(tài)，逐步趨向于復(fù)雜、混亂和無序的狀態(tài)發(fā)展，直到軟件不可維護(hù)而被迫下線或重構(gòu)。顯而易見，對于從事軟件系統(tǒng)開發(fā)的商業(yè)組織而言，熵增的后果就是無法滿足客戶需求導(dǎo)致的收入減少和成本居高不下。而業(yè)界多年成功和失敗的經(jīng)驗已經(jīng)證明，軟件系統(tǒng)熵增的根本導(dǎo)因就是架構(gòu)設(shè)計被忽視。

例如大多數(shù)軟件項目都采用了快速迭代的開發(fā)方法，即從軟件的一小部分重要功能模塊開始開發(fā)，逐步增加新的功能模塊。這種方法帶來好處的同時也帶來了問題，系統(tǒng)開發(fā)過程中會不斷引入新的要素（功能模塊），這些新的要素的引入很可能會打破原本已經(jīng)存在的要素之間的連接（功能模塊之間的關(guān)系）。如果在開始開發(fā)之前沒有進(jìn)行架構(gòu)設(shè)計，將所有重要的要素都找出來、理清要素之間的連接并證明其可以支持系統(tǒng)達(dá)成最終的目標(biāo)，那么在開發(fā)過程中就會需要不斷進(jìn)行重構(gòu)，或者因為“技術(shù)無法實現(xiàn)”而放棄某些功能。

架構(gòu)穩(wěn)定，才能積累能力

得到App《啟發(fā)俱樂部》第29期《能力如何增長？》中有這樣一段話：

能力增長，不是兵來將擋水來土掩，遇到問題解決問題的結(jié)果。而是一開始就有一個初始架構(gòu)，這個架構(gòu)不提供答案，但它提供了一組永恒的問題，同時屏蔽了那些不指向能力積累的解決方案。

玩兒過 Linux 的程序員應(yīng)該都聽說過“神的編輯器" Emacs，這是一款 1975 年開始開發(fā)并至今仍有用戶使用文本編輯器，而它居然還能支持多種 1990 年代后出現(xiàn)的編程語言的開發(fā)與調(diào)試。相似的例子還有 Eclipse，它除了作為最初的 Java IDE，還被改造為多種其它用途。

為什么這些軟件能夠經(jīng)過數(shù)十年的發(fā)展依然經(jīng)久不衰，支撐了在當(dāng)年不可能預(yù)見的需求；而有很多軟件產(chǎn)品每隔三五年就要進(jìn)行一次完全的翻新、不能在最初的版本上進(jìn)行向前兼容的演進(jìn)，不斷積累能力？因為在進(jìn)行軟件產(chǎn)品開發(fā)前沒有進(jìn)行必要的架構(gòu)設(shè)計，這樣就根本找不到那“一組永恒的問題”。于是面對客戶的“定制需求”時，就只能“真的定制”，給出無數(shù)不能指向能力積累的解決方案。

這種狀態(tài)不僅導(dǎo)致軟件系統(tǒng)的交付周期延長、質(zhì)量下降，也會導(dǎo)致提供軟件產(chǎn)品或服務(wù)的商業(yè)組織大量收入變?yōu)槌杀径鵁o法成為利潤。

軟件系統(tǒng)的架構(gòu)如何描述

關(guān)于軟件系統(tǒng)的架構(gòu)如何表達(dá)方法，在行業(yè)里爭論就比較多了，由于所處的環(huán)境和工作背景的不同，每個人的理解都不太一樣。但目前在行業(yè)中，有一些共識是架構(gòu)的表達(dá)需要分層分類，不可能簡單的用一張 PPT 就描繪清楚軟件系統(tǒng)架構(gòu)的所有問題。

行業(yè)中比較常見的關(guān)于架構(gòu)分層分類的方法是：業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)、技術(shù)架構(gòu)。這些詞被放到不同的環(huán)境中時，其具體含義也會發(fā)生一些變化，但其底層邏輯是一致的。

• 業(yè)務(wù)架構(gòu)：對于軟件系統(tǒng)開發(fā)者而言，其最終的目的是為了實現(xiàn)客戶的概念目標(biāo)（戰(zhàn)略目標(biāo)），而概念目標(biāo)往往是一些比較含糊的描述，并沒有給出具體的實現(xiàn)方法；因此概念目標(biāo)必須被拆解為具體的業(yè)務(wù)目標(biāo)，即通過開展哪些業(yè)務(wù)，怎么開展來把概念目標(biāo)實現(xiàn)；在業(yè)務(wù)目標(biāo)出現(xiàn)后，能推導(dǎo)出系統(tǒng)的功能目標(biāo)，即系統(tǒng)應(yīng)該具有哪些功能模塊。概念目標(biāo)，往往是客戶的高層領(lǐng)導(dǎo)關(guān)注的，業(yè)務(wù)目標(biāo)則是具體的業(yè)務(wù)負(fù)責(zé)部門領(lǐng)導(dǎo)關(guān)注的，而功能目標(biāo)則是軟件系統(tǒng)的操作者關(guān)注的。業(yè)務(wù)架構(gòu)的核心是把要實現(xiàn)軟件系統(tǒng)業(yè)務(wù)目標(biāo)所需要的業(yè)務(wù)有哪些（要素），這些業(yè)務(wù)之間的關(guān)系（連接）是什么講清楚。把業(yè)務(wù)搞清楚，不僅僅是架構(gòu)的問題，也是真正理解用戶需求，并且給出明確的問題解決方法的過程，而這也是業(yè)務(wù)專業(yè)性的體現(xiàn)。

• 應(yīng)用架構(gòu)：業(yè)務(wù)架構(gòu)設(shè)計是在不考慮軟件實現(xiàn)方式的前提下進(jìn)行的，如何實現(xiàn)業(yè)務(wù)設(shè)計以及如何體現(xiàn)信息化給業(yè)務(wù)帶來的價值提升則是應(yīng)用設(shè)計階段要解決的問題，在這個階段就要進(jìn)行應(yīng)用架構(gòu)的設(shè)計。應(yīng)用架構(gòu)為子系統(tǒng)劃分了明確的邊界，深刻影響系統(tǒng)功能組織、代碼開發(fā)、部署和運維等各方面。應(yīng)用架構(gòu)定義系統(tǒng)有哪些模塊或子系統(tǒng)、以及它們之間如何分工和合作。同時，系統(tǒng)的可擴展性、可配置性問題，往往也需要在應(yīng)用架構(gòu)設(shè)計階段給出答案?？梢钥闯?，做業(yè)務(wù)架構(gòu)設(shè)計的人，不一定要懂技術(shù)知識，但做應(yīng)用架構(gòu)設(shè)計則是要同時擁有業(yè)務(wù)知識和一定的技術(shù)知識。

• 數(shù)據(jù)架構(gòu)：數(shù)據(jù)架構(gòu)要回答的是軟件系統(tǒng)重數(shù)據(jù)的來源、數(shù)據(jù)模型、數(shù)據(jù)存儲或其分布、數(shù)據(jù)流向以及數(shù)據(jù)管理的相關(guān)內(nèi)容。

• 技術(shù)架構(gòu)：技術(shù)架構(gòu)關(guān)注的是軟件系統(tǒng)的實現(xiàn)問題，其中包含了從技術(shù)選型、代碼開發(fā)、測試到最終部署的各種問題。

在上述四類架構(gòu)設(shè)計工作中，應(yīng)用架構(gòu)通常是最為薄弱的環(huán)節(jié)，因為業(yè)務(wù)架構(gòu)可以由不特別懂技術(shù)的人做，技術(shù)架構(gòu)可以由不特別懂業(yè)務(wù)的人做，而應(yīng)用架構(gòu)需要能深刻理解業(yè)務(wù)又懂技術(shù)的人做，這樣的能力往往需要多個工種的工作經(jīng)驗和長時間的積累才能獲得。當(dāng)然，應(yīng)用架構(gòu)做的越好，也越容易給商業(yè)組織帶來競爭力。

結(jié)語

如前文所述，如果在軟件系統(tǒng)開發(fā)前，沒有將架構(gòu)問題解決，那么會給開發(fā)工作帶來無盡的麻煩。而對于從事 TO B 軟件產(chǎn)品或服務(wù)開發(fā)的商業(yè)組織而言，因其所提供的產(chǎn)品或服務(wù)要面對不同客戶，也一定會面對不同客戶的不同需求所帶來的定制化問題，架構(gòu)設(shè)計的重要性就更加不言而喻。

因此在產(chǎn)品或服務(wù)的立項階段和研發(fā)過程中的設(shè)計階段，就必須將業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)中的關(guān)鍵問題描述清晰，并且該產(chǎn)品或服務(wù)的功能越多、部署方式越復(fù)雜就越需要認(rèn)真完成這一工作，不可繞過。如果只是把 UI/UE 設(shè)計完成就開展相關(guān)的研發(fā)工作，一定會在熵增的路上越陷越深。