溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“如何理解軟件架構設計分層模型和構圖”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解軟件架構設計分層模型和構圖”吧！
對于架構思維本身仍然是類似系統思維，結構化思維，編程思維等諸多思維模式的一個合集。由于架構的核心作用是在業務現實世界和抽象的IT實現之間建立起一道橋梁，因此架構思維最核心的就是要理解到業務驅動技術，技術為最終的業務服務。要真正通過架構設計來完成業務和技術，需求和實現，軟件和硬件，靜態和動態，成本和收益等多方面的平衡。
在前面多篇文章已經提出，架構設計中有兩個重點，一個是分解，一個是集成。
分解是最基礎的，架構的重點就是要對復雜問題進行分而治之，同時保證分解后的各個部分還能夠高內聚，松耦合，最終又集成為一個完整的整體。分解核心是定義問題，因此架構首先仍然需要理解清楚需求。
集成是配合分解完成的動作，最終分解完成的各個組件或子系統，通過合適的接口設計，最終還能夠集成為一個完整的整體，分解僅僅是加速開發和降低問題復雜度，如果分解后的內容無法集成在一起，那么分解就沒有任何意義。
分解+集成可以理解為架構最核心的思考方式和方法。
在分解完成后，一個大的系統已經拆分為了諸多的小模塊，或者一個小模塊實現本身又分為了多個步驟階段。那么零散的節點必須向上匯集和歸納，形成一個完整的架構。
而這個架構的形成要給關鍵就是要又分層思維。架構分層是談架構絕對繞不開的一個點，通過架構分層可以更好地全面理解業務系統或功能實現。
在規劃大架構的時候，常會參考云計算的標準三層架構，即IaaS層，PaaS層，SaaS層。對于IaaS層重點是IT基礎設施和虛擬化；PaaS層重點是構建平臺層服務能力；而對于SaaS層則是具體的應用。
對于資源層從物理資源，再到虛擬化邏輯資源，從虛擬機到現在更加輕量的容器資源。而對于平臺層原來只談技術平臺，但是當前又進一步拆分出業務平臺，也可以理解成當前說得比較多的中臺層。
同時在平臺層和應用層之間增加了服務層，實現資源和服務的解耦。
如果涉及到物聯網類應用，一般還會在底層增加網絡層和感知層，比如一個智慧城市標準平臺和應用的架構圖類似如下：
在平臺+應用構建模式下，一般在平臺和應用之間還會有一個單獨的服務層來實現接口服務對外的能力開放。資源+服務+應用也是我們常說的SOA分層架構模式，因此對于服務層也可以單獨拆分出來作為一個小分層。
問題1：數據庫和數據層
在構建一個完整的總體架構的時候，實際上沒有數據層這個概念，數據層是在表達單個應用系統的分層架構實現的時候才會出現的內容。
在總架構圖里面把類似結構化數據庫，非結構化數據等全部列出單獨一層這個也不對，這個應該是在技術架構里面體現。
還有一種是單獨分出一個數據層，將大的公共基礎數據列出，比如上面談的智慧城市架構圖。如果這些基礎數據存在共性能力朝上提供，那么可以歸納到PaaS平臺層，在PaaS平臺層單獨分出一個數據平臺域來進行體現。
問題2：服務層和服務
在構建整體架構的時候可以單獨出一個能力開放平臺或服務層，但是不用體現具體有哪些業務服務能力。因為單獨出業務服務能力本質已經屬于應用層內容，即應用又細化拆分為了業務中臺和前臺應用，中間銜接的服務。
我們可以參考網上的另外一個構圖，如下：
這個構圖既不像云平臺中的分層架構，也不像應用功能實現中的分層架構。實際可以看到如果體現單獨的支撐層，支撐層已經類似現在經常說到的業務中臺和能力提供。
那么整個架構應該為 技術平臺+中臺+應用 方式來進行構圖。
對于SOA架構分層，重點要體現的就是服務，對于組件本身是屬于邏輯資源層的概念，而對于服務則是資源對外暴露的能力抽象。
SOA架構分層重點就是要體現出獨立的服務層，注意不是畫服務總線，這里可以單獨畫出具體提供哪些業務服務能力，技術服務能力。在采用SOA架構進行開發的時候，整體業務系統拆分為4個組件，10類服務域，5類流程，那么在構建的時候重點就是將上述組件，服務域和流程類體現出來。
對于參考SOA架構來進行的構圖，參考如下:
這里的數據層最好改為標準的組件層，更加貼近SOA架構模型。在圖中的服務層已經可以看到一個個獨立的API服務接口。如果服務接口數據大，一般只會劃分到服務域，比如用戶中心服務，采購類服務等。在這種方式下構圖參考如下:
在上圖中結合了云和SOA兩種架構融合在一起，對于上圖中的服務層實際可以理解為組件資源層和服務接口層的融合。更好的構圖方式應該是拆分為標準的中臺資源層-服務層-應用層。
注意對于云分層架構重點強調的是基礎設施，平臺和應用三層架構。而對于SOA架構強調的是資源，服務和應用三層。而對于對于傳統的應用系統的構建一般又包括了IT基礎設施，技術平臺，數據庫，中間件和應用。再到應用系統本身的分層架構可能又是標準的三層架構模式等。
這些架構分層方法都幫助我們進一步融合分層架構模式。
架構分層有很多方法，包括基礎設施層，平臺層，組件層，支撐層，服務層，應用層，數據層，展現層等。多種分發導致分層模型反而出現歧義和模糊。
在這里我們從技術架構和應用架構兩個層面來談，技術架構沿用云計算的三層模型；而對于應用架構則采用eTOM模型標準的資源，服務，應用三層模型。那么兩種分層架構模型的融合則是一個完整的云和SOA融合的分層架構模型。
即云計算的三層中，每一個層次本身又可以進一步拆分為資源，服務和應用三層。
拿IaaS層來說，最底層的物理資源虛擬機等是屬于資源層內容，通過IaaS層資源能力提供API接口作為技術服務進行能力開放，即是服務層；最終基于資源能力，構建了一個公有云的面向公眾的運營服務平臺，本身又屬于應用層的內容。而對于SaaS層，則底層的業務組件是資源，抽象的API接口是服務層，最終的前端業務或流程是應用功能實現。
回到單個應用的架構分層，談得最多的就是常說的三層架構模式。在軟件架構中，經典三層架構自頂向下由用戶界面層（User Interface Layer）、業務邏輯層（Business Logic Layer）與數據訪問層（Data Access Layer）組成。
在整個實現過程中，可能還會增加獨立的Facade層，或獨立的API接口服務提供層，統一的DTO數據傳輸對象層等，但是這些都不影響整體的三層邏輯結構。
三層架構本身也和一個業務功能實現的完整對應，在數據訪問層處理數據獲取和持久化操作，在業務邏輯層對業務規則進行處理，在界面展現層進行相應的前端展現和用戶交互。
而談到領域建模的時候，又引入了領域模型中的分層架構，如下：
領域驅動設計在經典三層架構的基礎上做了進一步改良，在用戶界面層與業務邏輯層之間引入了新的一層，即應用層（Application Layer）。同時，一些層次的命名也發生了變化。將業務邏輯層更名為領域層自然是題中應有之義，而將數據訪問層更名為基礎設施層（Infrastructure Layer），則突破了之前數據庫管理系統的限制，擴大了這個負責封裝技術復雜度的基礎層次的內涵。
當然，也有融合了領域模型和傳統三架構思路后的技術架構如下：
領域層和業務邏輯層
在領域建模的一個核心是領域模型，領域模型不再是一個個獨立的數據庫表或數據對象，而是一個業務對象或領域對象。因此領域層是面向領域對象而設計實現，而業務規則能力本身也是屬于領域對象對外提供的能力接口。即業務規則本身也是領域對象暴露的能力。
傳統業務邏輯層實現往往是一個數據對象對應一個DAO，一個Service和一個Interface。而領域模型下DAO可以是分開的，但是Service邏輯層往往則更多應該按領域模型思路對DAO層的能力進行組裝和聚合。
獨立應用層拆分
在我原來理解里面，領域層提供領域模型和領域服務能力接口，而應用層更多的是對領域層多個領域對象模型提供的服務能力進一步進行組裝和編排，然后再暴露給前端應用。
談到應用層的概念，實際上可以理解為前端應用中存在的共性能力的進一步下沉。即應用本身只是用戶業務功能實現的承載，但是這個功能的實現可以通過多種前端展現形式，比如傳統的CS桌面應用，BS應用，或手機端APP。
在電商里面，一個商品訂購就是一個獨立的應用，用戶可以在APP完成，也可以在BS端完成，但是不論在哪里完成最終應用層提供的能力都應該一樣。比如完成一個商品訂購需要同時和底層的訂單，庫存，支付多個服務進行交付和協同。那么這個邏輯顯然不適合同時在BS端應用和APP端應用中進行重復編寫和開發。那么這個內容就應該在應用層實現。
如果回到微服務和中臺架構下，這個應用層拆分更加必要，即通過應用層來下沉共性的服務組合和組裝邏輯，這個邏輯和協同不應該屬于任何一個前端應用。
界面層還是接口層
在開發一個聚合能力的中臺微服務模塊的時候，可以看到這個微服務模塊本身并沒有界面展現層，那么該微服務的最上層僅僅是提供API接口的接口服務層。
該API接口服務能力既可以提供給APP前端，也可以提供給BS端使用。
軟件技術架構構圖，分層仍然可以沿用軟件三層分層模型，重點是說明清楚各層用到的關鍵技術組件或技術服務能力。比如軟件開發三層模型的技術架構分層如下：
如果本身就是一個技術平臺，類似大數據平臺，那么我們在整體構圖的時候仍然需要考慮先進行分層，再詳細說明每層里面的技術內容。
比如對應一個大數據平臺，包括了大數據采集，大數據存儲，大數據處理，大數據分析和應用，那么這個就是關鍵的分層，可以基于這個分層再來考慮各層采用的關鍵技術。
對于技術棧構圖基本也可以參考技術架構構圖模式進行。
技術架構重點需要回答的就是你在進行軟件架構設計過程中，究竟會用到哪些關鍵技術，哪些開源產品或工具等。可以細化到具體的技術產品，也可以僅細化到產品類型。
比如消息中間件，你可以細化到采用RabbitMQ，也可以在技術架構中只體現采用消息中間件。
技術架構和軟件功能分層架構唯一相同的就是分層，技術架構在各個分層里面都沒有具體的業務功能點和實現內容，僅僅是關鍵技術點說明。
注意應用功能架構完全是重點描述應用系統具備哪些功能，一個功能究竟是采用什么三層技術架構實現并不用關心。因此功能架構不應該體現數據層，邏輯層，技術點這些內容。
那么對于一個應用系統的功能如何分層？
我們可以參考業務分層分類，將業務分為基礎支撐層，執行層，決策管理層。這樣基本的分層模式就出來了，基于該方式可以完成一個功能架構構圖。
對于單個應用來說一般不會自身有云平臺，PaaS平臺這類概念。但是單個應用構建一定存在共性技術支撐平臺能力，比如有自己的流程管理，各自共性技術功能組件等。因此單應用構建還可以采用基礎技術支撐層+應用層+門戶層的方式進行構圖。
在應用層再按具體的業務域或業務階段進行進一步細分。
在前面基本給出了不同類型的架構圖的核心分層邏輯，可以看到在畫架構圖的時候盡量不要混合使用不同場景下的構圖方式，否則就導致整體架構圖混亂。
在畫整體架構的時候一般需要重點參考云三層架構，SOA三層架構的構圖模式進行構圖。而在細化到某一個應用系統的時候，仍然還需要分清是構建技術架構圖還是功能架構圖，兩者本身的分層邏輯也存在很大的差別而不能混用。
架構圖的構圖邏輯
要完成一個完整的架構圖構圖，可以先拆分為兩邊+中間。兩邊一般是放具體的標準，規范等，比如安全管理，質量管理，技術標準規范，開發運維規范等。
中間即是重點需要考慮進行分層構建的地方。
在前面也談到了中間部分重點參考云計算和SOA的架構分層邏輯。一般來說核心的還是資源層，平臺層，應用層，門戶層。而對于應用層本身又可以考慮業務域進一步拆分，或者根據價值鏈或業務生命周期拆分為多個階段域再展開描述。
在云和SOA下，更加強調平臺+應用構建模式。
而兩者之間一般是服務層，通過SOA平臺或API能力開放平臺來統一接入和發布服務，以形成一個完整的資源+服務+應用的松耦合架構。
同時一個完整的架構本身就是多視角的，如下：
功能架構往往可以給具體用戶和業務人員看，而對于技術架構往往更多是內部團隊開發人員研討使用。而設計到資源和平臺的架構圖往往又是運維工程人員進行部署架構搭建的重要參考。因此不同維度的架構分層屬性本身不能隨意融合使用，而導致架構圖混亂。
感謝各位的閱讀，以上就是“如何理解軟件架構設計分層模型和構圖”的內容了，經過本文的學習后，相信大家對如何理解軟件架構設計分層模型和構圖這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
