企業整體架構是什麼，有什麼用，怎麼作，如何落地，這些東西聽起來很是抽象，作起來也是很是抽象。軟件工程從開始到結束通常會經歷需求、分析、編碼、測試、部署、維護6個階段，每一個階段都會固定的輸出物，例如剛開始的產品需求文檔（PRD），後面的架構設計文檔等。一個應用架構設計的造成不僅僅是技術上，是統籌性的輸出，通常分爲：功能清單，用例及活動圖，領域圖，接口設計，分層設計，業務代碼，其餘設計。在現狀中，梳理出現狀有如下幾個點redis
企業商務模型設計 功能架構設計 用例及活動圖設計 領域架構設計 接口模型設計 分層模型設計 企業商務模型設計 一個軟件的成型過程當中，設計上就須要對整個商務模型進行分析，這是最重要的一環，雖說作技術出身不用去作商務模型的從0-1的過程，可是須要作到從1-2的過程，把整個商務模型轉化起來並進行落地。企業裏面全部應用系統的都是創建在企業商務模型之上，它是爲整個應用系統提供方向性指導。在一個商務模型裏面，基本涉及了主營業務，商務模式，運營模式，主營產品，競品分析和業務流程等。不少公司在開始作應用軟件以前，總體的商務模式基本上已是清楚的，此時的設計階段就趨向於需求調研階段。spring
圖1：某公司CRM基礎商務模型數據庫
主營業務指的是工做是以什麼業務爲生；商務模式即公司如何賺錢；運營模式比較複雜，企業內部的人力資源管理，財務管理，技術管理，生產運營管理，市場營銷管理五部分組成；主營產品比較好理解，便是公司所服務或者銷售的主要產品，通常是公司裏面的拳頭產品；競品分析，不知道哪位大佬說過，有人的地方就有江湖，有產品的地方就有競品。客觀上來講，競品分析是從競爭對手或者市場上的相關產品中，針對特定的考察角度，分析出現狀狀況以及跟本身的產品進行對比，必須客觀而且真實，作橫向對比（圖2及圖3）；業務流程指主營業務從產生到最後出門的整個流轉過程，最終目的都是盈利。編程
圖2：醫療信息化市場規模及其預測後端
圖3：近10年中國人口數量及人口增加率安全
功能架構設計 在功能設計上要作好，通常從三個方面切進去：功能設計，角色設計，資源權限設計。springboot
2.一、功能設計 功能設計上通常以模塊爲類別，由大模塊開始不斷下放到各個小功能最終組成功能性圖表，同時展現了全部功能的從屬關係（圖4）。網絡
圖4：春雨醫生功能架構設計架構
2.二、角色設計 每個系統都會進行角色設計，指的是系統裏面有多少角色，通常角色在定義的時候是根據業務須要來制定。以角色定義業務，以業務定義模型。前後端分離
3W原則：3W原則是最多見的作法，WHO，WHAT，HOW這三者來區分。
WHO：用於描述主要運用於哪些角色？這些角色是幹嗎的？在整個3W體系中，相對於用戶體驗上來講，這個是最重要的存在，系統的使用者，企業的業務使用方，領導層，決策層關心所關心的每每就是本身能經過這個角色看到什麼內容，經過這些內容能判斷出或者從中獲取對企業有幫助的信息，例如往年規劃，接下來可能會發生的事情等。
WHAT：用於描述具體作什麼業務，在這一層裏面更趨向於具體的業務使用人員，每個系統的使用人員須要很是清楚本身到底是作什麼？
HOW：在上面知道作什麼後，接下來系統要幫助的就是怎麼作的問題。從系統的產生到系統的消亡，每個軟件都是有必定的生命週期的，這個生命週期本質上來源於業務的不斷變化，映射出業務也是有必定的生命週期，在這個系統裏面，要告知每個業務使用人員，業務是如何經過這個系統怎麼作？
轉存失敗 從新上傳 取消 3W原則舉例
2.三、資源權限設計 資源權限設計對於全部後臺系統來講，是一個最重要的部分，主要是針對不一樣人能夠訪問不一樣的資源權限，接口權限，數據權限等，這些權限的控制上的缺乏或者操做問題引起的風險，是很是巨大的，最直接的後果就是致使數據串聯了從而隱私數據泄漏。
目前不少公司採用微服務進行設計開發，權限系統天然須要獨立出來並實現獨立的管理，整個權限設計中，從簡單到複雜分爲7種，RBAC0模型，RBAC1模型，RBAC2模型，RBAC3模型，用戶組，組織，職位，含有組織/職位/用戶組的模型。
RBAC0模型
RBAC1模型
RBAC2模型
組織
職位
含有組織/職位/用戶組的模型
以上7種模型的設計主要仍是集中在資源權限的設計上，也就是咱們最多見的菜單級別的設計，這一塊的設計對於整個系統來講是最重要也是最基礎的存在，是後面咱們要進行接口權限，數據權限權限的根基。接口的權限設計的顆粒度是以每一個接口中做爲資源的顆粒度，這個接口是與每一個服務進行掛鉤並由超級管理員統一分配給上面的角色或者用戶，在進行數據受權的時候統一處理好並返回給用戶，這一層的設計上有多種多樣，若是存在網關的存在，在進行鑑權的時候通常都放在網關上並結合redis進行鑑權。數據權限比較簡單，每一個服務或者每一個系統都有本身特定的業務權限數據範圍，根據角色獲取這些角色可訪問的數據範圍便可。
備註：接口的鑑權上，能夠採用接口註冊->接口分配的方式進行，接口註冊能夠自定義註解進行自動註冊或者手動在後臺的接口管理上進行手動添加，若是是自動註冊的話，通常後臺設計上不容許修改，避免影響接口的訪問，可是提早約定好規則。
3大資源鑑權整合參考
用例及活動圖設計 用例圖是很是常見的圖，在UML的全部圖中，它應該算是最須要而且最快須要肯定的圖，每個用例圖跟產品功能上存在對應關係。
用例圖是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關係構成的用於描述系統功能的視圖。用例圖（User Case）是外部用戶（被稱爲參與者）所能觀察到的系統功能的模型圖。用例圖是系統的藍圖。用例圖呈現了一些參與者，一些用例，以及它們之間的關係，主要用於對系統、子系統或類的功能行爲進行建模。
用例圖舉例
用例活動圖是從用例圖拓展而來，每個用例活動圖展開後便可變成用例活動圖，從兩個角度來分析對用例活動圖的內容
產品經理：產品經理從用例活動圖，獲取到的是總體或者個體的業務邏輯。
研發人員：研發人員從用例活動圖，獲取到的是總體或者個體的程序上的業務邏輯。
業務用例工做流程說明了業務爲向所服務的業務主角提供其所需的價值而必須完成的工做。業務用例由一系列活動組成，它們共同爲業務主角生成某些工件。工做流程一般包括一個基本工做流程和一個或多個備選工做流程。工做流程的結構使用活動圖來進行說明。
工做流程活動圖用於研究實現業務目標時所要執行的各項任務或活動的順序安排。活動既能夠是手動執行的任務，也能夠是自動執行的任務。它可完成一個工做單元。
活動圖是狀態圖的一種特殊形式。其中全部或多數狀態都是活動狀態，並且全部或多數轉移都在源狀態中的活動完成時當即觸發。
用例活動圖舉例
領域架構設計 在以往的設計中，領域架構設計每每並無出現，從用例開始後總體就開始進入到系統的接口設計，可是微服務的出現致使領域驅動設計開始流行。
領域架構設計中咱們今天不深究，今天這部分只說說領域圖的設計。領域圖是從用例活動圖演變而來，相對於用例圖，它是整個用例的細化展現。領域圖是應用程序中的業務邏輯模型，它的每個對應的方框可大可小，或是子系統、或是服務、或是類庫、或是單個類，實現微服務的本質性可伸縮性、可拓展性。
領域模型在整個面向對象的設計中是最簡單，也是最困難的一部分，對於一個領域模型來講，在面向對象的設計中有個重要的思想就是把事情交給最合適的類去作，這須要不斷是聯絡各個類之間的關係，從語言層面來說，它具有 5 方面的特性：
一、存在父類，專門用來存儲全部子類的公共屬性，而且這個類並非一個值對象。
二、存在實例的字段
三、存在實例的屬性
四、存在本身的領域邏輯，具像化來理解就是存在公共的與私有的方法
五、存在本身的領域服務，這個領域服務是靜態方法static，而且這個方法能夠單獨放出來放到特定的服務類中。
領域模型圖舉例
接口模型設計 接口模型設計在如今的先後端分離的系統中是最重要的，直接關係到應用的便捷性。
應用的多樣化須要咱們在對接口進行設計的時候多考慮接口的邊界問題，能夠參考：《springboot2.2.X手冊：構建多元化的API接口，咱們這樣子設計 》。
每個接口都有生命週期，如何去管理能夠參考：《微服務手冊：API接口9個生命節點，構建全生命週期管理 》。
那回歸接口本質，接口實際上是一種契約精神，一種約定俗成的規則，一種應用與外部世界的鏈接者，一種應用與其餘應用的交互者，是讓整個業務能成功流轉起來的源頭，可是接口並不關內心面的具體實現，這些是服務層的事，可是接口有個通用性的原則，那就是必定遵循請求與輸出Request/Response。
接口文檔舉例
分層模型設計 在第五點的接口設計中，接口並不關心服務層的具體實現，可是分層模型設計中關心的就是邏輯的具體實現。如今最經常使用的分層設計中，最多見的仍是三層架構的設計，雖然領域橫行，可是學習成本是個很是須要考慮的問題，總體在進行分層中堅持的思想是：分層越簡單明瞭，理解起來就越簡單，代碼越容易統一編寫，相對於整個工程來講，這樣子的結構是最有利於業務的快速迭代，並讓這個系統更加穩定可靠。在作總體的分層設計的時候，儘量保持不要爲了炫技而作設計，要考慮更多同窗的學習力的問題。目前小編除了在接口層作領域的區分外，其餘的仍是堅持原來的三層設計，這樣子新來的同窗能夠很快上手，「面向領導」編程更有優點了。
其餘項 除了上面說的，還有數據庫設計，物理架構設計，非功能性設計等。數據庫設計通常有E-R圖與表設計，數據設計規範等；物理設計有部署圖，高可用或者集羣部署圖，域名等；非功能性設計通常主要把安全放在第一位，其他是性能、高可用、彈性伸縮、拓展性等。最後整合成一份完成的架構設計文檔。
--END--
做者：@溪雲閣
原創做品，抄襲必究
如須要源碼，轉發，關注後私信我
部分圖片或代碼來源網絡，如侵權請聯繫刪除，謝謝！