架構設計中有兩(liǎng)個重點，一個是分解，一個是集成(chéng)。

分解是最基礎的，架構的重點就(jiù)是要對(duì)複雜問題進(jìn)行分而治之，同時(shí)保證分解後(hòu)的各個部分還(hái)能(néng)夠高内聚，松耦合，最終又集成(chéng)爲一個完整的整體。分解核心是定義問題，因此架構首先仍然需要理解清楚需求。

集成(chéng)是配合分解完成(chéng)的動作，最終分解完成(chéng)的各個組件或子系統，通過(guò)合适的接口設計，最終還(hái)能(néng)夠集成(chéng)爲一個完整的整體，分解僅僅是加速開(kāi)發(fā)和降低問題複雜度，如果分解後(hòu)的内容無法集成(chéng)在一起(qǐ)，那麼(me)分解就(jiù)沒(méi)有任何意義。

分解+集成(chéng)可以理解爲架構最核心的思考方式和方法。

在分解完成(chéng)後(hòu)，一個大的系統已經(jīng)拆分爲了諸多的小模塊，或者一個小模塊實現本身又分爲了多個步驟階段。那麼(me)零散的節點必須向(xiàng)上彙集和歸納，形成(chéng)一個完整的架構。

而這(zhè)個架構的形成(chéng)要給關鍵就(jiù)是要又分層思維。架構分層是談架構絕對(duì)繞不開(kāi)的一個點，通過(guò)架構分層可以更好(hǎo)地全面(miàn)理解業務系統或功能(néng)實現。

對(duì)于資源層從物理資源，再到虛拟化邏輯資源，從虛拟機到現在更加輕量的容器資源。而對(duì)于平台層原來隻談技術平台，但是當前又進(jìn)一步拆分出業務平台，也可以理解成(chéng)當前說(shuō)得比較多的中台層。

問題1：數據庫和數據層

在構建一個完整的總體架構的時(shí)候，實際上沒(méi)有數據層這(zhè)個概念，數據層是在表達單個應用系統的分層架構實現的時(shí)候才會(huì)出現的内容。

在總架構圖裡(lǐ)面(miàn)把類似結構化數據庫，非結構化數據等全部列出單獨一層這(zhè)個也不對(duì)，這(zhè)個應該是在技術架構裡(lǐ)面(miàn)體現。

還(hái)有一種(zhǒng)是單獨分出一個數據層，將(jiāng)大的公共基礎數據列出，比如上面(miàn)談的智慧城市架構圖。如果這(zhè)些基礎數據存在共性能(néng)力朝上提供，那麼(me)可以歸納到PaaS平台層，在PaaS平台層單獨分出一個數據平台域來進(jìn)行體現。

問題2：服務層和服務

在構建整體架構的時(shí)候可以單獨出一個能(néng)力開(kāi)放平台或服務層，但是不用體現具體有哪些業務服務能(néng)力。因爲單獨出業務服務能(néng)力本質已經(jīng)屬于應用層内容，即應用又細化拆分爲了業務中台和前台應用，中間銜接的服務。我們可以參考網上的另外一個構圖，如下：

這(zhè)個構圖既不像雲平台中的分層架構，也不像應用功能(néng)實現中的分層架構。實際可以看到如果體現單獨的支撐層，支撐層已經(jīng)類似現在經(jīng)常說(shuō)到的業務中台和能(néng)力提供。

那麼(me)整個架構應該爲 技術平台+中台+應用 方式來進(jìn)行構圖。

對(duì)于SOA架構分層，重點要體現的就(jiù)是服務，對(duì)于組件本身是屬于邏輯資源層的概念，而對(duì)于服務則是資源對(duì)外暴露的能(néng)力抽象。

在上圖中結合了雲和SOA兩(liǎng)種(zhǒng)架構融合在一起(qǐ)，對(duì)于上圖中的服務層實際可以理解爲組件資源層和服務接口層的融合。更好(hǎo)的構圖方式應該是拆分爲标準的中台資源層-服務層-應用層。

注意對(duì)于雲分層架構重點強調的是基礎設施，平台和應用三層架構。而對(duì)于SOA架構強調的是資源，服務和應用三層。而對(duì)于對(duì)于傳統的應用系統的構建一般又包括了IT基礎設施，技術平台，數據庫，中間件和應用。再到應用系統本身的分層架構可能(néng)又是标準的三層架構模式等。

這(zhè)些架構分層方法都(dōu)幫助我們進(jìn)一步融合分層架構模式。

架構分層有很多方法，包括基礎設施層，平台層，組件層，支撐層，服務層，應用層，數據層，展現層等。多種(zhǒng)分發(fā)導緻分層模型反而出現歧義和模糊。

在這(zhè)裡(lǐ)我們從技術架構和應用架構兩(liǎng)個層面(miàn)來談，技術架構沿用雲計算的三層模型；而對(duì)于應用架構則采用eTOM模型标準的資源，服務，應用三層模型。那麼(me)兩(liǎng)種(zhǒng)分層架構模型的融合則是一個完整的雲和SOA融合的分層架構模型。

即雲計算的三層中，每一個層次本身又可以進(jìn)一步拆分爲資源，服務和應用三層。

拿IaaS層來說(shuō)，最底層的物理資源虛拟機等是屬于資源層内容，通過(guò)IaaS層資源能(néng)力提供API接口作爲技術服務進(jìn)行能(néng)力開(kāi)放，即是服務層；最終基于資源能(néng)力，構建了一個公有雲的面(miàn)向(xiàng)公衆的運營服務平台，本身又屬于應用層的内容。而對(duì)于SaaS層，則底層的業務組件是資源，抽象的API接口是服務層，最終的前端業務或流程是應用功能(néng)實現。

領域驅動設計在經(jīng)典三層架構的基礎上做了進(jìn)一步改良，在用戶界面(miàn)層與業務邏輯層之間引入了新的一層，即應用層（Application Layer）。同時(shí)，一些層次的命名也發(fā)生了變化。將(jiāng)業務邏輯層更名爲領域層自然是題中應有之義，而將(jiāng)數據訪問層更名爲基礎設施層（Infrastructure Layer），則突破了之前數據庫管理系統的限制，擴大了這(zhè)個負責封裝技術複雜度的基礎層次的内涵。

領域層和業務邏輯層

在領域建模的一個核心是領域模型，領域模型不再是一個個獨立的數據庫表或數據對(duì)象，而是一個業務對(duì)象或領域對(duì)象。因此領域層是面(miàn)向(xiàng)領域對(duì)象而設計實現，而業務規則能(néng)力本身也是屬于領域對(duì)象對(duì)外提供的能(néng)力接口。即業務規則本身也是領域對(duì)象暴露的能(néng)力。

傳統業務邏輯層實現往往是一個數據對(duì)象對(duì)應一個DAO，一個Service和一個Interface。而領域模型下DAO可以是分開(kāi)的，但是Service邏輯層往往則更多應該按領域模型思路對(duì)DAO層的能(néng)力進(jìn)行組裝和聚合。

在我原來理解裡(lǐ)面(miàn)，領域層提供領域模型和領域服務能(néng)力接口，而應用層更多的是對(duì)領域層多個領域對(duì)象模型提供的服務能(néng)力進(jìn)一步進(jìn)行組裝和編排，然後(hòu)再暴露給前端應用。

談到應用層的概念，實際上可以理解爲前端應用中存在的共性能(néng)力的進(jìn)一步下沉。即應用本身隻是用戶業務功能(néng)實現的承載，但是這(zhè)個功能(néng)的實現可以通過(guò)多種(zhǒng)前端展現形式，比如傳統的CS桌面(miàn)應用，BS應用，或手機端APP。

在電商裡(lǐ)面(miàn)，一個商品訂購就(jiù)是一個獨立的應用，用戶可以在APP完成(chéng)，也可以在BS端完成(chéng)，但是不論在哪裡(lǐ)完成(chéng)最終應用層提供的能(néng)力都(dōu)應該一樣(yàng)。比如完成(chéng)一個商品訂購需要同時(shí)和底層的訂單，庫存，支付多個服務進(jìn)行交付和協同。那麼(me)這(zhè)個邏輯顯然不适合同時(shí)在BS端應用和APP端應用中進(jìn)行重複編寫和開(kāi)發(fā)。那麼(me)這(zhè)個内容就(jiù)應該在應用層實現。

如果回到微服務和中台架構下，這(zhè)個應用層拆分更加必要，即通過(guò)應用層來下沉共性的服務組合和組裝邏輯，這(zhè)個邏輯和協同不應該屬于任何一個前端應用。

界面(miàn)層還(hái)是接口層

在開(kāi)發(fā)一個聚合能(néng)力的中台微服務模塊的時(shí)候，可以看到這(zhè)個微服務模塊本身并沒(méi)有界面(miàn)展現層，那麼(me)該微服務的最上層僅僅是提供API接口的接口服務層。

該API接口服務能(néng)力既可以提供給APP前端，也可以提供給BS端使用。

軟件技術架構構圖，分層仍然可以沿用軟件三層分層模型，重點是說(shuō)明清楚各層用到的關鍵技術組件或技術服務能(néng)力。比如軟件開(kāi)發(fā)三層模型的技術架構分層如下：

如果本身就(jiù)是一個技術平台，類似大數據平台，那麼(me)我們在整體構圖的時(shí)候仍然需要考慮先進(jìn)行分層，再詳細說(shuō)明每層裡(lǐ)面(miàn)的技術内容。

技術架構重點需要回答的就(jiù)是你在進(jìn)行軟件架構設計過(guò)程中，究竟會(huì)用到哪些關鍵技術，哪些開(kāi)源産品或工具等。可以細化到具體的技術産品，也可以僅細化到産品類型。

比如消息中間件，你可以細化到采用RabbitMQ，也可以在技術架構中隻體現采用消息中間件。

技術架構和軟件功能(néng)分層架構唯一相同的就(jiù)是分層，技術架構在各個分層裡(lǐ)面(miàn)都(dōu)沒(méi)有具體的業務功能(néng)點和實現内容，僅僅是關鍵技術點說(shuō)明。

注意應用功能(néng)架構完全是重點描述應用系統具備哪些功能(néng)，一個功能(néng)究竟是采用什麼(me)三層技術架構實現并不用關心。因此功能(néng)架構不應該體現數據層，邏輯層，技術點這(zhè)些内容。

那麼(me)對(duì)于一個應用系統的功能(néng)如何分層？

我們可以參考業務分層分類，將(jiāng)業務分爲基礎支撐層，執行層，決策管理層。這(zhè)樣(yàng)基本的分層模式就(jiù)出來了，基于該方式可以完成(chéng)一個功能(néng)架構構圖。

對(duì)于單個應用來說(shuō)一般不會(huì)自身有雲平台，PaaS平台這(zhè)類概念。但是單個應用構建一定存在共性技術支撐平台能(néng)力，比如有自己的流程管理，各自共性技術功能(néng)組件等。因此單應用構建還(hái)可以采用基礎技術支撐層+應用層+門戶層的方式進(jìn)行構圖。

在前面(miàn)基本給出了不同類型的架構圖的核心分層邏輯，可以看到在畫架構圖的時(shí)候盡量不要混合使用不同場景下的構圖方式，否則就(jiù)導緻整體架構圖混亂。

在畫整體架構的時(shí)候一般需要重點參考雲三層架構，SOA三層架構的構圖模式進(jìn)行構圖。而在細化到某一個應用系統的時(shí)候，仍然還(hái)需要分清是構建技術架構圖還(hái)是功能(néng)架構圖，兩(liǎng)者本身的分層邏輯也存在很大的差别而不能(néng)混用。

架構圖的構圖邏輯

要完成(chéng)一個完整的架構圖構圖，可以先拆分爲兩(liǎng)邊+中間。兩(liǎng)邊一般是放具體的标準，規範等，比如安全管理，質量管理，技術标準規範，開(kāi)發(fā)運維規範等。

中間即是重點需要考慮進(jìn)行分層構建的地方。

在前面(miàn)也談到了中間部分重點參考雲計算和SOA的架構分層邏輯。一般來說(shuō)核心的還(hái)是資源層，平台層，應用層，門戶層。而對(duì)于應用層本身又可以考慮業務域進(jìn)一步拆分，或者根據價值鏈或業務生命周期拆分爲多個階段域再展開(kāi)描述。

在雲和SOA下，更加強調平台+應用構建模式。