作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有雲PaaS平台架構設計經驗，長期從事一線項目實踐

今天準備再詳細講解下業務系統軟件架構設計方面的内容，我在前面的文章專門寫過一篇軟件架構師應該走出技術狂熱誤區，鍛煉核心架構思維能力的文章。

在這篇文章裡面我對架構思維做了一個簡單總結。

其核心仍然是我們常說的分解，集成，抽象，複用，分層等思維模型。感興趣的可以先閱讀這篇文章的一些内容。軟件架構師應走出技術狂熱誤區，鍛煉核心全局思維能力

在這篇文章裡面更多的是篇架構思維和企業架構方面的内容，因此今天這篇準備從單個業務系統的架構設計來談下軟件架構設計的核心邏輯和内容。

對于軟件架構設計，相信很多人都看過溫昱寫的一本《軟件架構設計》書籍，而對于我這篇文章重點會參考企業架構，RUP架構設計和這本書的一些思想做一些展開。

架構設計包括了功能性架構和技術架構設計兩個部分的内容，功能性架構解決業務流程和功能問題，而技術架構解決非功能性需求等問題。兩種架構都包括了動态和靜态兩個方面的内容，對于功能性架構中動态部分為業務流程驅動全局用例，用例驅動的用例實現等；對于技術架構中動态部分為架構運行機制，而靜态部分為框架，分層等方面的内容。

功能性架構包括了全局用例設計，這個本身是用例分析和設計的一個延續，而全局用例分析建議的思路仍然是業務流程，業務用例建模到系統用例建模的過程。

全局用例分析清楚後可以開始考慮子系統和模塊的劃分，形成系統的功能架構圖，當然在劃分過程中一定要考慮到通過CRUD矩陣等分析方法來分析模塊如何劃分合理，如何保證模塊本身高内聚和松耦合。

即我們說的從00-用例視圖如何過渡到01邏輯視圖架構。

在全局用例分析完成後涉及到數據模型的設計，數據建模仍然從業務驅動，從最初的業務對象和單據入手，到最終的數據概念模型和邏輯模型等。

架構設計中全局數據模型不一定覆蓋所有的數據對象和數據表；但是核心的主數據，核心業務單據數據一定要覆蓋到，模型到的層次到邏輯模型即可。如果用面向對象的分析方法，這裡需要出的是UML建模中的概念模型和邏輯模型，體現核心對象和類，核心對象和類之間的關系。

将全局用例分析和數據模型建立融合在一起，可以看到這兩者結合起來會形成一個系統完成的領域模型層。一直認為領域模型思路應該引入架構設計，隻有領域模型才是真正關注功能性架構，而不用馬上關注到具體的技術分層和技術實現。

前面兩者做完後可以看到一個大系統被分解為了多個子系統或模塊，那麼接着要考慮的就是模塊間的集成架構，分析完集成架構模塊間的接口基本就出來了。接口設計應該是架構設計的另外一個核心内容。要明白架構設計一個重要作用就是架構設計完成後各個模塊可以并行開始概要設計，詳細設計和開發工作。隻要大家都遵循架構設計約定的接口規則即可以了。

以上正好是架構視圖中的01邏輯視圖的關鍵内容。

集成架構考慮完另外一個核心内容就是公共可複用組件的抽取和識别，包括了功能組件和技術組件，需要識别出來哪些是可複用的，如何進行複用。對于複用層次本身又包括了數據層複用，邏輯層組件複用，界面層UI組件的複用等。複用是架構價值體現的的另外一個關鍵點。

這些都做完後，接着一個步驟應該在架構設計階段做的就是對架構輸出成功進行模拟驗證，前面完成了分解動作，必須通過模拟驗證來看看後續分解内容能否很好的集成和組裝。很多時候我們做架構設計的時候往往不做這塊内容，導緻架構設計一些内容變成空中樓閣，無法落地。

再回來看技術架構設計，首先談下靜态部分的内容。這裡面就包括了軟件開發的分層架構，開發框架等内容，包括開發規範約定，技術平台和語言的選擇，使用的規約等都需要考慮。這些可以看到剛好是4 1架構視圖裡面的02開發視圖的内容。很多時候我們看到談架構的時候說到的三層或多層架構，僅僅是完整架構設計裡面很小的一部分内容。

除了分層架構外，接着考慮的就是各種非功能性需要，我們在架構上需要如何設計。

這裡面包括了事務，緩存，異常，日志，安全，性能，可用性，容錯能力等。這些逐個點都要在架構設計中說清楚如何考慮，由于這些本身就屬于一個應用系統中技術平台要考慮的内容，因此應該設計為較為公用的技術組件供上層的業務組件使用。要明白很多時候為何談到AOP或可插拔架構，隻有這樣去考慮問題，才會考慮真正的功能性架構設計和功能實現和非功能性技術架構這塊充分解耦，實現進一步的靈活裝配。而這個對應架構視圖裡面的03進程視圖。

再回到架構設計視圖層面，還需要考慮的就是整個應用系統的部署架構，部署架構本身也包括了邏輯視圖和物理視圖，應用最終開發出來了如何進行部署，這涉及到了IT基礎架構方面的細化，也需要考慮清楚。即架構視圖裡面的04部署視圖。

一說到軟件架構設計包括的内容，我們比較容易想到的就是傳統RUP和面向對象分析和設計裡面經常談到的4 1架構視圖，如下：

從這個圖也更好的解釋了軟件架構應該包括功能性架構和非功能性架構兩方面内容。

邏輯視圖即是從功能需求視角，邏輯視圖更多的就是組件劃分，組件間的依賴關系，當然你可以進一步細化到核心的類和類關系圖。但是一般來講搞清組件和組件間關系最重要。

對于非功能性需求實際有兩個方面的考慮。

• 開發态：即技術和開發框架選擇，開發分層模型
• 運行态：系統集成視角，進程視圖，對于性能和可擴展性的考慮

當然RUP更加強調的是用例驅動，即最中心的是用例視圖，用例視圖是展開後續架構分析設計的基礎。如果熟悉RUP方法論也可以看到，對于用例實現的分析才能夠識别出關鍵的實體類，控制類和邊界類，在類識别出來後才能夠進行後續的組件劃分和接口集成分析等。

在我寫這篇文章的時候，到網上搜索關于RUP架構設計的資料，發現最近幾年基本沒有更新的技術資料，難道是當前敏捷開發和微服務不需要完整的架構設計了？實際上我們看到當前很多微服務項目建設後續出現大量緊耦合，低性能等問題，完全是由于前期架構設計不充分導緻。錯誤的将采用類似SpringCLoud框架作為我們完成架構設計是當前最大的問題點。

當我重新翻閱了下多年前寫過的軟件架構設計文檔，基本即是參考RUP架構設計展開。

但是在進行架構設計的時候，實際我們已經有一些重要的輸入，一個是來自于業務系統本身，一個是來源于組織級技術資産積累。

• 業務系統：核心是産品需求和軟件需求，已經進行業務建模和業務組件劃分
• 組織資産：包括技術平台，技術組件，技術框架标準，可複用技術清單等

這些一方面是業務系統進行架構設計的輸入，同時也是架構設計的關于約束。架構設計一方面是要實現業務目标和需求，一方面又必須滿足關鍵約束。這些約束可以技術框架要求，開發語言和數據庫要求，多中心化的要求等等，這些在架構設計的時候都必須考慮到。

基于以上思考和近期的項目實踐，對于軟件架構設計文檔我們給出一個新的參考，但是其核心仍然是圍繞業務，數據，應用，技術幾個維度展開。

即一個完整的軟件架構設計應該包括如下内容：

基于該圖，有幾個關鍵說明如下：

對于架構設計文檔可以拆分為軟件架構設計，數據庫設計，部署架構設計三個獨立文檔。而實際我們項目建設和實踐三個文檔基本也進行拆分。

其次對于軟件架構設計文檔應該從架構目标約束出發，基于業務需求和用例輸入，進行功能性架構設計和非功能性架構設計，同時在這裡将技術開發框架和分層架構設計單獨出獨立章節，即不管是MVC還是SSH，都是标準分層框架模型，你隻需要講清楚架構運行機制即可，不需要和實際業務功能相關。

在關鍵架構設計内容梳理清楚後，我們再講解下架構設計文檔的核心内容邏輯。

如果熟悉RUP方法論的可能都清楚，在RUP統一過程方法論裡面有三個核心。其一是用例驅動，其二是架構為核心，其三是增量疊代方法論。

在用例分析和設計中，基本梳理清楚了核心的業務功能點，核心的業務對象，同時在詳細的用例需求文檔裡面還有詳細的業務基本流，擴展流和業務規則描述。

在傳統的用例分析裡面我們沒有太去強調業務域的劃分和業務架構概念，但是這個實際仍然是需求階段一個重要的内容。即通過用例分析後我們需要對用例點進行聚合，形成一個業務架構模型圖。

這個業務架構圖形成了基本的業務模塊或業務組件，如下：

在我們原來的整個軟件生命周期管理裡面，除了軟件需求外，還會有一個獨立的産品需求文檔，即在産品需求文檔裡面會進行産品業務模塊-》業務單元-》業務功能的分層定義。

也就是說在需求階段完成了業務建模，并完成了業務組件劃分。

有了産品需求和業務架構，那麼架構設計階段就有了重要的參考。但是如果你沒有完整的業務建模，那麼在架構設計階段，需要首先做的就是業務組件劃分。

對于組件的劃分，我在前面一篇文章中給出了一些指導原則可參考：

中台規劃中微服務粒度究竟應該如何劃分？你可以從以下幾點考慮

那麼劃分的核心點究竟在哪裡？

我們通過組件劃分要達到高内聚和松耦合，但是這個是劃分後的目标而不是方法。真正劃分的方法仍然是圍繞業務功能，業務數據，業務流程三者之間的各種CRUD功能和數據交互分析。

通過交互分析你才能夠發現真正的哪些業務功能或業務數據應該聚合在一起。

邏輯視圖首先要解決組件劃分

對于邏輯視圖，對原來的方法做一定的修正。

即傳統架構視圖裡面的邏輯視圖更多的是核心類和類關系視圖，而個人理解在架構設計階段并不一定要細化到這個層次，更加重要的是組件劃分和組件關系集成視圖。

即在邏輯視圖設計的時候，需要首先進行組件劃分，組件劃分的方法可以參考業務建模，如果沒有業務建模可參考那麼就需要重新進行業務，數據，流程的CRUD分析來劃分組件單元。

而對于組件劃分的方法，我們可以理解為最傳統的縱向劃分思路和當前結合了領域建模和SOA分層架構思想的分層組件劃分思路。

我們先看一個傳統的組件劃分的例子，如下：

上圖就是一種典型的縱向劃分思路，即業務組件 開發分層模型形成組件劃分和組件架構圖。而這種組件劃分和設計思路，是很難真正體現我們常說的領域模型設計邏輯的。

基于SOA和領域模型設計的思路，更多的我們應該是首先找到共性的領域層服務能力，然後再基于領域模型能力來構建上層的業務功能和流程功能。

即從縱向組件劃分思路=>SOA和領域分層模型構建思路。

橫向分層有點類似你首先去考慮構建領域模型，再來考慮上層業務功能，上層的業務功能模塊和領域模型層的組件不再是簡單的縱向1對1關系。這個和當前我們做中台架構規劃設計很類似，即先考慮如何構建中台共性業務能力，再來考慮前台業務功能如何劃分組件。

我基于PLM系統常見的文檔管理，ITEM管理，産品結構和變更管理等業務功能組件模塊，基于分層構建的思路重新對組件劃分和組件模型進行重構，參考如下：

在這裡基于個人理解再強調一點，在我們進行架構設計中的邏輯視圖設計的時候，一開始務必不要陷入到技術開發框架的分層模型中去。而是應該找尋最核心的領域模型。

為什麼這樣講？

領域模型更多的體現了核心的領域實現邏輯，這個領域模型本身是和你采用的技術開發框架無關的，你可能是三層MVC框架，也可能是其它的前後端四層框架等等，但是這些本質上都不影響到你領域模型的設計。這是領域模型的技術無關性。

也就是在RUP的邏輯視圖不應該過早陷入到架構分層模型中。

對于技術框架和架構分層，本身是一個完全技術概念，和邏輯模型相反的地方是其本身和業務無關，但是任何的業務功能具體實現，都必須遵循分層架構和層級業務和數據調用流轉機制。

當我們理解到這點後，就更加容易理解邏輯視圖和開發視圖的關系，即如下：

注意組件劃分不是一成不變，你開始的組件劃分可能并不合理，這個可以在後續用例實現的過程分析中對個别功能點的歸屬進行調整。

這也是我們說的架構分析設計過程也是一個不斷疊代和求精的過程。

當然在需求階段，我們就應該形成一個全局用例分析圖。

在這裡我們做兩個關鍵說明，即如下

• 不是對所有用例進行實現分析，隻對關鍵用例進行
• 用例實現分析隻到組件，而不是到具體的類

對于第一點大家容易理解，一個架構設計不可能對所有的用例進行分析。那麼什麼是關鍵用例？比如你當前有一個文檔管理模塊，那麼對于文檔的增删改查功能實現是否是關鍵用例？

那麼我的答案是這種不是關鍵用例，我們對關鍵用例給出一個新的定義，即關鍵用例往往是跨了多個組件協同才能夠完成的用例。如果一個用例實現在一個組件内部就能夠搞定，那麼我們可以把這部分工作放到概要設計或詳細設計去做，而不是在架構設計階段完成。

當我們對關鍵用例完成分析後，你會發現組件之間的集成和協同關系也就出來了。而且這個時候你很清楚為何組件之間存在這麼一個集成點。

将所有的集成點都找到後，組件間的集成關系圖也就基本清楚了。

那麼再下一步就是基于集成點梳理接口清單。

對識别出來的接口進行分析，看哪些接口需要拆分，哪些接口需要合并，接口服務如何保證我們常說的粗粒度特性。在這個步驟完成後才能夠形成完整的接口清單。

到了這裡我們基本完成了邏輯視圖最核心的内容，即具體應該分為哪些組件，這些組件如何協同來完成關鍵用例實現。組件之間的接口集成關系是如何的，接口如何抽象和複用。

當然你可以看到邏輯視圖可以再進一步細化，比如對于組件關系圖你可以進一步細化到類關系圖，對于關鍵用例實現可以細化到類之間的詳細方法定義和交互。即邏輯架構設計再朝下面細化了一步，但是整體細化仍然和我們前面談到的邏輯架構分析設計思路一緻。

開發架構關注軟件開發環境下實際模塊的組織。軟件打包成小的程序塊（程序庫或子系統），它們可以由一位或幾位開發人員來開發。子系統可以組織成分層結構，每個層為上一層提供良好定義的接口。系統的開發架構用模塊和子系統圖來表達，顯示了"輸出"和"輸入"關系。完整的開發架構隻有當所有軟件元素被識别後才能加以描述。但是，可以列出控制開發架構的規則：分塊、分組和可見性。

再次強調下如果你自己沒有完成過一個全新系統的架構設計，那麼你很難真正了解到架構設計的完整内容。作為一個架構師必須既了解業務，又了解技術，同時做好業務到技術的抽象轉換，做好業務和技術之間的橋梁和承接。

你掌握SSH三層框架，或者說你使用SpringCloud微服務框架，完成框架搭建，搞清楚裡面的每一個技術組件的作用可能一周時間足夠。或者類似你基于Hadoop整個技術體系搭建一個完整的大數據平台，了解數據存儲，處理，分析等關鍵技術組件估計1到2個月也足夠。但是你學會後不能叫架構師，核心原因還是架構不能脫離業務，架構是需要業務驅動去解決業務場景和問題的。

脫離業務實際上就沒有架構設計，最多隻能夠算的上架構設計中的技術框架選型。但是我們看到，如果你不清楚具體的業務需求和目标，你連究竟技術框架如何選型也不清楚。

一個好的架構一定不是用最先進的技術，而是用最适用的技術，是真正的業務目标驅動你要用哪些技術，而不是當前流行什麼我必須采用什麼技術。

在前面有篇文章裡面我就談到過，當前有些技術人員一味的使用新技術，新框架來搭建企業技術平台和開發框架，而不是從企業實際業務需求和架構約束出發。在這個過程中自己能力提升了，技術框架不适用自己可以一走了事，但是企業卻很受傷。這不再是簡單的技術人員技術狂熱問題，而已經是一種個人自私自利行為表現。

那麼對于一個開發視圖究竟應該包含哪些内容，我們參考網上的一個說法：

簡單來說開發架構就是需要技術框架選型，開發的分層架構，開發标準規範體系，開發技術選型，這些屬于标準的和業務功能模塊無關的内容。

其次就是我們說的基于已有的邏輯視圖和功能，你在開發的時候應該如何劃分項目，如何分包，整個項目源代碼的結構是如何的，各層和各層之間的關系是如何的。

也就是我前面談到的邏輯視圖 技術框架分層=完整的開發視圖

在邏輯視圖中的要給組件實現，如果在開發視圖中往往可能會體現到多個分層的Package包，比如我們常說的數據層，邏輯層，展現層等。

同時我們考慮到開發的需要，一個大的業務系統我們可能一開發就拆分多個獨立的開發項目進行管理，每個項目都可以進行獨立的構建和編譯。那麼整體的開發視圖分層應該為：

開發項目（子系統）=》開發包（分層）=》開發功能（具體類文件）

一個完整的開發架構除了選擇一種标準的技術開發框架外，更加重要的就是你需要定義清楚具體的開發項目劃分，項目裡面的目錄和分層結構，類文件的命名規範，接口的定義和調用規範等。

這些規範和開發要求将指導我們進行每一個業務功能點的開發。即使最簡單的一個業務功能你也可以看到需要具體在每層寫哪些類文件，哪些接口和接口實現文件，哪些配置文件等。

在開發架構下，對于邏輯架構裡面的組件架構圖會得到進一步的細化。

即原來的組件粒度-》變化為分層構件粒度。

其次，在開發架構中，我們還需要考慮會引用哪些外包的開源組件，第三方的SDK包等。這些内容屬于通用技術框架内容，在邏輯架構設計階段我們一般不會關心。

我們還是用前面的例子進一步說，一個PLM系統包括文檔，産品，變更三個大模塊。如果整體我們就一個開發項目，在開發項目内部進行分包，我們開發架構類似如下：

在開發架構構建過程中，我們将文檔管理，産品管理和變更管理三個模塊建立三個獨立的項目，同時當變化為三個獨立項目後，我們要求原來包内組件間的依賴，隻能夠存在業務邏輯層相互依賴和調用，不能再出現跨模塊和跨層的依賴調用以減少拆包後的耦合關系。

基于以上場景，我們整個開發架構變化為：

再次，當我們進一步進行前後端分層，同時将數據庫訪問層進行統一，即數據訪問層建立一個統一的開發項目提供對外的數據訪問接口。而對于前端開發合并為一個項目進行。而在領域服務層，我們進一步将原來領域邏輯歸類到文檔服務和産品服務兩大領域服務，不再有具體的變更領域服務的概念。

對于文檔和産品兩大領域服務可以看做是中台的兩個大微服務模塊，也采用分項目獨立開發構建的模式進行。那麼在這種變化下，我們的開發架構視圖如下：

通過前面幾種場景的比較，主要是想說明開發架構更多的是要說明我們的組件如何分包和分層，組件的開發如何與我們當前的技術框架選型，我們的開發模式相互結合。

而這些屬于開發态的内容，需要在開發态才能夠看得更加清楚。

那麼開發視圖和運行視圖之間的差别又在哪裡呢？

到了進程或部署視圖，我們就隻能夠看到具體的獨立部署單位，比如上圖，隻能夠看到數據層一個獨立的JAR包，邏輯層兩個獨立的JAR包文件，前端一個獨立的JAR包文件。但是對于JAR包文件裡面具體的包劃分，分層劃分在運行态或運行視圖我們是看不到的。

我們先摘錄一段網上關于進程視圖的描述，如下：

進程架構考慮一些非功能性的需求，如性能和可用性。它解決并發性、分布性、系統完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與進程結構相配合在一起－即在哪個控制線程上，對象的操作被實際執行。

進程架構可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構可以視為一組獨立執行的通信程序（叫作"processes"）的邏輯網絡，它們分布在整個一組硬件資源上，這些資源通過 LAN 或者 WAN 連接起來。多個邏輯網絡可能同時并存，共享相同的物理資源。

進程是構成可執行單元任務的分組。進程代表了可以進行策略控制過程架構的層次（即：開始、恢複、重新配置及關閉）。另外，進程可以就處理負載的分布式增強或可用性的提高而不斷地被重複。軟件被劃分為一系列單獨的任務。任務是獨立的控制線程，可以在處理節點上單獨地被調度。

大家看了上面的進程視圖描述啥感覺？

實際上我們看到在業務系統的架構設計裡面往往并不涉及到這麼複雜的進程和任務處理邏輯。如果你是設計一個微服務底層架構或消息中間件，我們感覺會出現類似上面的進程視圖描述。

比如我們看Dubbo的技術實現框架，就類似于一種進程視圖的表現方式。

但是對于大部分業務系統來說，往往并沒有複雜的進程視圖需要描述。

但是進程視圖更多的是運行架構和運行态的軟件質量屬性總結。

即我們常說的運行态的安全，性能，擴展性，可靠性，吞吐量等都需要在運行視圖和運行架構中進行描述。而這些恰好是我們前面提到的非功能性架構設計的基礎。

當然對于非功能性架構設計，運行視圖是主要内容，而對于開發架構，部署架構仍然需要提供對非功能性架構能力的支撐。比如我們常說的高并發和性能問題，那麼你在開發框架和技術選擇上就需要考慮，其次在部署架構本身的擴展性上也需要考慮。

對于高可用，高性能和高擴展的非功能性架構設計，我準備單獨再寫一篇文章來說明，不在這篇文章進行展開。

歡迎關注@人月聊IT 分享SOA，微服務，DevOps平台規劃和建設。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!