團隊架構

研發團隊的總體架構設計方案

寫在前面

企業總體架構是什么,有什么用，具體怎么做呢？以我曾任職的公司為案例，一起來探討這個問題.這家公

司當時有200位研發人員和200多臺服務器，我剛進這家公司時,他們的系統就已經玩不下去了,總是出

現各種問題，例如日常發布系統時或訪問量稍微過大時，系統就會出現很多故障，而且找不到故障發生的

根本原因。

我進這家公司后的主要任務就是對這個系統進行升級改造,花了一個半月的時間寫了那份企業總體架構文

檔，文檔共有124頁,直接指導了之后的技術改造,下圖是那份文檔的目錄。

一、企業商務模型

企業商務模型的內容主要包括主營業務、商務模式、商務主體、競品分析、組織架構、商務運作模型和業

務流程等.

主營業務即公司做什么業務，商業模式即公司怎么賺錢，商務主體即哪幾個人在一起做這門生意，競品分

析即了解競爭對手的情況，組織架構即公司部門是怎么劃分的。組織架構圖中標出人數,根據系統與業務之

間對應關系，可以了解系統中哪些模塊使用頻率高，以及業務與其對應模塊的復雜度.商務運作模型即公司

是如何運作的,售前做計劃，找供應商把東西買進來后，經過服務和結算,再賣給我們的經銷商和采購商，使

我們獲得利潤,售后進行大數據分析最后又指導著我們的售前，整個過程形成良性循環。可以把一家公司想

象成一臺機器，輸進去的是錢,轉一轉后，又能夠生出更多的錢出來。

最后是業務流程和更多業務資料下載，業務流程包括預訂流程、訂單處理流程、產品供應流精彩開頭 程、財務結算

流程、賬戶管理流程。企業商務模型的建立，指導著整個應用系統模型的建立，畢竟系統是為業務服務的。

1

二、架構現狀

架構現狀的內容主要包括：功能架構、應用架構、數據設計和物理架構。

功能架構

功能架構主要包括功能、角色和權限三部分。功能是企業服務,用戶使用的每一個功能，就是企業的每一個

服務。角色是用戶操作的歸類，功能與角色的對應關系即權限。了解系統架構的現狀,從功能架構開始。

應用架構

應用就是處理器，應用架構的內容包括現有架構圖、Web應用現狀、作業小應用（Job)現狀和接口架構。

其中,接口是應用層面的關鍵，它是一個程序與另外一個程序交互的部分.

應用架構圖表列出了哪些業務邏輯沒有被重用，換句話說業務邏輯被多少個應用調用，就需要被重復開發

多少次，一旦改了一個地方，就要同時改多個地方，導致系統開發效率非常低下。各業務邏輯如預訂邏輯，

雖然被多個應用調用，但它們與應用是沒有關系的，業務邏輯可以獨立的存在，也可以寄宿于多個應用。

業務邏輯是一個業務操作的抽象,而業務應用與業務部門共同完成了業務操作。

數據設計

100多個數據庫,一萬多張表，能否使用一張E-R圖來表示呢？它是可以的。*＊數據設計依賴于企業的

數據，而鼻炎的原因 不是數據庫的設計，對企業數據適當做歸類，會直接導致數據設計,最終畫出E—R圖，數據設計

完成后，數據庫設計就自然而然出來了。超越庫、超越表去看這張E-R圖，可以看出它包括產品、訂單、

結算、用戶、基礎設施這五類數據。低層的E—R圖可以變,但是高層的E-R圖一般不會變化,因為它是根

據你的業務模型而定，業務模型穩定，高層E—R圖也是穩定的。數據庫只要早期設計得好，是可以做到

易伸縮、易拆分的。下圖從內往外看，一個框既可以是一個庫，也可以是一個模塊,還可以是一個表。在業

2

務發展的早期它可以是一個庫，里面有5個模塊，中期可以分為5個庫，后期以更低級別可以分為更多

的庫,這與業務階段及系統復雜度相關。在數據的設計完成后，數據庫的設計也就很容易規劃和調整。

以上是數據庫、數據表之間的靜態關系喝彩 ，接下來我們介紹數據的流轉狀態即狀態圖。通過數據狀態圖去了

解現有數據流轉變遷，如國內訂單狀態變遷圖，這種圖的價值不僅在于數據庫層，還在于服務化.圖中的從

等待支付到支付成功，中間有個支付行為，通過這個支付行為把數據狀態變更為支付成功，否則繼續等待，

直到超時關閉訂單.這個支付行為可以做成一個微服務，然后由不同的應用去調用.

物理架構

物理架構的內容主要包括IDC機房、機房之間訪問關系、機房內服務器物理部署圖、機房與業務分布、

網站架構、數據庫架構、集群清單和域名清單。將這些內容以列表和圖形方式整理出來，就會很容易了解

和發現問題,只有紙上談兵的典故 發現問題才能解決問題，特別是在全局體系架構方面，這也是表和圖的價值所在。當時這

家公司共有5個地區、8個機房，雖然只有200多臺服務器，但分布很散，導致物理結構復雜,通訊也

很復雜.技改前故障不斷，其主要的一個原因就是物理架構不合理，運維要占60%、70％的責任，當時卻

把責任歸咎為應用架構，這是個錯誤的方向。物理架構的不合理,應用架構是很難合理的,因為物理架構是

我們的基礎設施，位于最底層，下層為上層服務，運維要為應用服務，應用要為業務服務，業務要為客人

服務.

三、領域模型

領域模型關注概念,關注職責、關注邊界、關注交互，只有先確定職責和邊界，交互才會很清晰.領域模型是

針對現有問題域提出一個系統解決方案，然后在圖表上建立完整的模型，如同用AutoCAD畫的施工圖紙

一樣。領域模型屬于概要設計階段，對于單個應用架構設計，首先需要了解業務和功能需求、用例圖、用

例活動圖，然后才是領域模型。業務流程圖是對業務操作的抽象,領域圖是對業務邏輯代碼的抽象.

3

建立領域詞匯是建立領域模型的第一步，它能統一詞匯明確概念，以減少一詞多義、一義多詞的情況。概

念一旦確定，再擴展屬性和行為,然后把它當作一個單元與其它事物構建在一起，就會很容易形成模型,領

域模型與企業商務模型中的業務流程圖有參考對應關系.領域模型在實現時可大可小,在業務的早期,在系統

比較小的情況下，它有可能是一個類。當系統做大了以后，它可能是個DLL庫。再做更大一點的時候，

它可能是一個服務，給不同的應用去調用。每一個方法都有成為服務的潛質，特別是在系統中后期.領域模

型是業務邏輯代碼的施工圖紙，它不僅有利于對現在系統業務邏輯的了解，同時也指導未來的架構改造。

四、架構規劃

當我們了解了業務、了解了架構的現狀，發現現有架構的問題，接下來就可以做中遠期架構規劃，以及架

構的調整和具體實施。架構規劃內容包括：頂層架構規劃、網站功能規劃、應用規劃、SOA規劃、分層架

構規劃、數據庫規劃和物理規劃等。

頂層架構規劃

上圖是頂層架構的俯視圖和側視圖.第一張圖是俯視圖，坐在飛機上看,整個頂層架構最外層的是功能，中

間的是業務操作，內層的是數據。功能對應業務系統的用戶界面，操作對應業務系統里的服務，數據對應

業務系統的數據存儲如數據庫。第二張圖是剖面圖，切一刀來看，上層是應用，中層是服務和框架,下層是

基礎設施數據中心。從圖中的服務層可以看出，服務的歸類跟業務流程的歸類有很大關系。

網站功能規劃

網站功能規劃就是功能的重新劃分，對照著架構現狀，未來的功能應該如何調整？如案例中的國內網站功

能規劃，分別畫出了全局功能圖、采購商功能圖、平臺商功能圖和供應商功能圖。其實在做網站功能規劃

的時候,更多需要考慮現狀,而不是未來調整的部分，如果沒有很大問題，則不做調整，尊重歷史.因為有些

東西（如名稱）用戶已經使用很久了，調整往往比較難,合理大于準確.

應用規劃

4

系統是什么,系統=元素+關系。應用架構是什么？應用架構=應用+架構。應用就是系統的最小單

元，應用分類和應用編號則構成了應用關系即應用的架構。如上圖中的案例，應用分類新建了框架Fx和

公共服務CBS，原有的應用架構中并沒有這兩個的，而是分布在了不同的業務線中,從而導致重復建設。

應用編號是給每個應用分配一個六位的數字ID，就如同我們的身份證一樣，頭兩位表示產品線，中間兩位

表示子系統,最后兩位表示應用，如100206。應用編號是應用管理、依賴和追蹤的基礎，集中式日志和監

控框架都有使用到應用編號.

SOA規劃

SOA規劃就是接口規劃世紀英文 ，它的歸類與商務模型中的業務流程有參考對應關系.上圖案例有五個服務中心：

預訂服務、訂單處理服務、產品供應服務、財務結算服務和公共服務。每個服務只需要實現一套自己的邏

輯，我們的前臺、后臺、接口、作業小應用等都可以調用，服務的邏輯跟我們的業務邏輯是一致的，修改

代碼的時候只需要改一個地方就可以影響到所有調用到這服務的前端應用。

分層架構

分層架構看似很簡單，但保證整個研發中心都使用統一的分層架構就不容易了。那么如何保證整個研發中

心都使用統一的分層架構呢，以達到提高編寫代碼效率、保證工程統一性的目的？先簡單介紹下當前兩種

比較流行的分層我的一天英文 架構體系,一種是領域架構:倉儲層RepositoryLayer、領域層DomainLayer、應用服務

層ApplicationLayer、表現層PrentationLayer和基礎公共層InfrastructureLayer，請見第一張圖;

另一種是相對傳統地分為三層：數據層DataLayer、應用邏輯層BusinessLayer和表現層Prentation

Layer,請見第二張圖。

領域架構和三層架構之間有什么區別？我們是這樣認為的，在早期我們做三層架構的時候，大都以表來做

驅動的，在做領域架構的時候，大都以業務邏輯來驅動的，兩者的區別確實比較明顯,但到了現在，如果都

以業務邏輯為中心的話，實際上兩者并沒有本質區別。當時,我所在公司采用了第二種分層法,我們希望把

5

分層做得極簡,也就是說哪怕剛畢業進來的員工，在分層時基本上也不會亂。而相對第一種分層法，第二種

分層法簡單很多。每一個應用的代碼量都不應該很大，一旦工程變得過大，我們就會把它適當拆分，而不

是全部放在一個單塊應用里。總之,我認為分層越簡單,整個軟件結構就越清晰，代碼就越容易統一。把工程

做得極簡，才有利于復制，有利于業務的快速構建，有利于規模化、穩定可靠。

數據庫規劃

數據庫是整個信息系統中生命周期最長、最難修改的部分，所以要加強規劃。數據庫的設計至少要提前兩

步,具體根據高層E-R圖和數據設計來新建數據庫,早建要比晚建好。數據庫調整的代價大、周期長,長時間

產生的問題，需要長時間來解決，先在新庫里解決新表，再根據當前業務和應用的需求，逐步調整舊表.

物理規劃

物理架構的規劃內容包括集群規劃和域名規劃。首先是集群規劃。20倍規劃、5倍設計和1.5倍實施:規

劃和設計要大一些，但實施時小一些，這樣不僅便于將來的擴展，也節省了當前的費用;兩個邏輯網絡：一

個內網和一個外網，兩個負載均衡，兩個防火關于朋友的名言 墻，安全隔離內外網；四條產品線：國際、國內、新業務以

及公共業務，單點登錄和企業支付網關等公共業務也屬于一條產品線;六個集群：Web集群、SOA集群、

中間件集群、數據庫集群、Job集群和ITD集群。以上橫向集群與縱向產品線形成了一個矩陣結構，也

基本確定了網絡基礎架構。對于域名規劃。對內的域名該改的改，該停用的停用，該合并的合并.對外的域

名要盡量少改，要改的話也要有歷史繼承性（如跳轉），要盡量減小對用戶的影響.

其它

除以上架構規劃外,還有一些其它重要項，如源代碼管理規劃、文檔管理規劃、技術選型和團隊分工。為什

么還要做這些呢？因為統一了源代碼怎么放、每個部門的文檔怎么放、將來要用什么工具版本，才利于團

隊的協作,基于統一的環境才能有更高層次地提升。對于團隊分工，需要逐步對齊組織架構與系統的架構規

6

劃。對于技術選型，需要注意中間件的引進,要有節奏性，力量要相對集中,要小規模試點,找非核心項目，

試用成功后再感恩活動 進行大規模推廣.

架構實施

做完架構規劃后，就是架構實施落地了。我們的架構實施整體思路是：樹目標、給地圖、立榜樣、抓重點、

造文化、建制度、整環境、組建架構部。架構部內招幾名老程序員，外招幾個架構師。內部走出去,提高眼

界。外部牛人請進來,落地了解歷史和業務。具體建議是:SOA服務化、基礎設施平臺化、公共業務服務化、

加強項目概要設計.當研發團隊達到200多人、有了幾百個應用，且在故障不斷的情況下，不能與以前一

樣沒有設計就開始編碼,而是做加強項目概要設計及評審。后面的補與前面的防，兩手都要抓，兩手都要硬.

具體計劃是：Roadmap分步實施，改造一期、改造二期、改造三期，近細遠粗、實事求是、逐步細化逐

步完善。不斷立技術改造項目,不斷將技改與業務研發項目相結合,技改即是工單、工單即是技改。避免對業

務過多地影響，并不斷有業務價值輸出，這是架構改造得以持續實施的關鍵!

以上簡單地介紹了總體架構的編寫方法,我們的編寫思路是先了解業務，建立企業商務模型，主要包括靜態

的商務主體、組織架構和動態的業務流程。再了解架構的現狀,建立現有信息系統模型，主要包括應用架構、

數據設計和物理架構。一個是商務,一個是電子，兩者即是整個公司的電子商務系統。然后在企業商務模型

和現有系統模型之上提出領域問題，建立領域模型。領域模型一般不會變，直接指導下一步的動作即架構

規劃。最后一定要落地，即架構實施。8月是什么星座 附檔是去掉敏感信息后的一個真實的電子商務案例，它的價值如下：

?

?

?

?

BigPicture，全局藍圖,起到方向性和指導性。

將隱性知識顯性化，方便傳達、廣而告之.

對于新員工的價值，快速入門。

對于老員工的價值，了解全局，過程梳理，然后專注于自己的部分。

7

關于企業總體架構，大家可以參考標準TOGAF(開放組體系結構框架)。

8