如何做架構設計？

也許您對軟體設計存在一些疑惑，或者缺乏明確思路，那么本文將非常適合您，

1、設計很重要

我們可以看一下周邊的事物，那些好的東西，他們并不會天然存在，都是被設計出來的，因此設計就是創造和改善事物的重要程序，設計的重要之處在于，最初的設計往往決定最終的結果，甚至決定著事物的長期的發展，例如兩個品牌的手機之間，他們可以使用同一個代工廠，但他們差異在設計時就已經決定了，

架構設計也是如此，我見過很多的軟體系統，他們經過了很多年的演進，在沒有完全重構的情況下，始終無法改變最初設計模樣，最初的設計決定了長期的發展，而對于業務深度耦合的系統，重構成本非常高，風險也非常大，變化也更加不確定，所以要更加重視設計，

我們要尋求更好的技術方案，推動架構的良性演進，每一步都是經過深度思考的，而架構設計方法就是幫助我們思考的框架，

通過做架構設計，我們應該提升軟體的質量和效率，降低風險和成本，

2、架構設計的目的是什么？

是為了解決軟體系統復雜度帶來的問題（架構的目標是用于管理復雜性、易變性和不確定性，以確保在長期的系統演化程序中，一部分架構的變化不會對其它部分產生不必要的負面影響，這樣做可以確保業務和研發效率的敏捷，讓應用的易變部分能夠頻繁地變化，對應用的其它部分的影響盡可能地小，）

要解決復雜度問題，首先需要識別復雜度的來源，主要集中在以下三個方面：

業務復雜度：流程多，參與者多、狀態和變數多等；由業務本身決定，但業務復雜不代表軟體系統復雜，例如作業流引擎并不復雜，但他可以做非常復雜的業務，在面對復雜業務時，我們常使用抽象思維，不要讓軟體邏輯與業務邏輯系結在一起，

技術復雜度：高性能、高可用、高可擴展、安全，成本、規模等；這部分復雜度常常由技術本身決定，也應該由技術本身解決，通常是采用更合理的框架和工具；避免這些技術特性穿透到應用層，也可以有所取舍，在不同業務情況下，采用不同的實作程度，

設計復雜度：職責不是最小的完備的、概念不清晰的、層次不清的、業務邏輯與技術實作系結的，組件過多以及關聯依賴復雜的；這部分是由設計不合理導致的，也是對業務系統影響最大的一部分，要通過良好的設計來解決，

3、架構設計的主要內容是什么？

找到系統中的元素并搞清楚他們之間關系（如果我們不知道系統是怎么運行的，那么他一定是很復雜的，對于龐大的軟體系統，如何才可以被掌控？這就需要將大系統分解為很元素，每個元素需要足夠簡單，并且元素與元素之間的關系清晰）

軟體架構是一種結構，結構中包含了一些元素和元素之間的關系描述；

元素的種類：系統、子系統、模塊，組件、服務、類、介面...

關系的種類：層次關系、資料關系、呼叫關系、影響力關系...

"架構表示對一個系統的成型起關鍵作用的設計決策，架構定系統基本就成型了，這里的關鍵性可以由變化的成本來決定，"-- Grady Booch. ）

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch.

4、架構設計有什么原則？

合適原則：“合適優于業界領先”， 真正優秀的架構都是在企業當前人力、條件、業務等各種約束下設計出來的，能夠合理地將資源整合在一起并發揮出最大功效，并且能夠快速落地，

簡單原則：“簡單優于復雜”， 優先使用直接的不復雜的方案解決問題；

演化原則：“演化優于一步到位”，軟體需要根據業務的發展不斷地變化，架構要不斷地在實際應用程序中迭代，在某個階段必定有所取舍，但架構的演化必須是低成本的，當業務發生變化時能夠最高效的迭代；在這個程序中修復缺陷的設計，積累優秀的設計；

5、架構師的職責是什么？

業務分析：梳理對業務和技術的理解和判斷、形成業務領域知識、明確的業務目標和本質的業務訴求；

系統建設：降低系統復雜性、規劃系統遠期架構、推動架構的合理演化；

技術方案：選擇合適的技術、提供對業務的解決方案，把控全域，包括質量、效率、成本、風險；

關鍵問題：攻克難點，解決關鍵問題，指導研發落地；

知識沉淀：以體系化的表達方式，面向不同人員的視圖語言，持續完善知識系統；

6、架構設計程序如何？

程序：全域分析業務 → 設計方案 → 概要設計 → 詳細設計 → 補充設計

視角：業務級 → 系統級 → 應用級 → 模塊級 → 技術級 → 代碼級 → 實施級；

架構師的協作鏈路較長，每一個程序都應該留下資料，越下游的角色往往需要更全面的資料；架構設計檔案應該包含架構師參與的所有環節，以及這些環節產生的圖文說明；不僅僅是空洞的結果，應該包含架構師的思路和想法；

全域分析階段

這階段需要對業務需求進行全面分析，需要將名詞羅列出來，區分名詞是功能、流程、名詞、參與者的哪一種，再通過分析業務的本質并找到其中的關鍵名詞，關鍵的名詞被稱之為領域，可以圍繞關鍵的領域構建業務模型；

在這個程序中，需要統一語言、識別核心領域、按照相關性將功能歸屬到對應的領域，對領域之間的關系做出必要的描述，輸出物是名詞與解釋、領域以及擁有的能力，業務架構，

名詞的概念必須是清晰的，領域的職責必須是明確的，領域擁有的能力必須是相關的；

其中業務架構可按照場景層、功能層、領域層、依賴層劃分，例如下圖；

設計方案階段

在完成全域分析之后，我們應該設計技術方案，盡可能提供多個備選方案的圖文說明，需要對備選方案做充分的優劣分析，最終取舍一項最合適的方案，沒有被選擇的方案（或者取舍的部分）也要被說明；

我們需要找到各項約束條件（時間、人力、硬體等），評估在約束條件允許的情況下，哪個備選方案更合適，我們可能考慮如下方面：

方案對業務影響：主要判斷需求覆寫程度、實作業務的短期目標、考慮業務的長期目標；

方案的技術需求：安全是否滿足、性能是否滿足、規模是否滿足、可維護性；

方案的可擴展性、方案的復雜程度、方案是否能夠演進、方案演進成本如何（高成本的 慎重考慮）、方案的影響力傳播如何（對上下游影響較大的 慎重考慮）；

架構設計階段-應用架構

用以說明當前系統的元素（系統、子系統、模塊，組件）以及他們之間的關系（層次關系、依賴關系）

重點是將可復用的組件抽象后下沉，越往下層越是穩定和通用，由上層承接不穩定的業務；

應用架構圖體現了層次關系，以及不完全體現了依賴關系，依賴只能是上層依賴下層，示例如下圖

架構設計階段-部署架構

用以說明支持應用所需要的硬體能力、以及外部中間件、網路、機房等情況；可參考下面兩張圖；

架構設計階段-資料架構

描述資料資產結構、存盤、流轉、災備的情況；最常用的是ER圖；

架構設計階段-技術架構

描述一些關鍵技術的說明，比如性能、安全、互動等；

描述技術選型和代碼框架的說明，比如DDD推薦的菱形對稱架構，文字和圖片描述都可以；

詳細設計階段

詳細設計是對質量的把關、是對研發落地的指導；

這部分涉及的內容較多，比如服務、事件、介面、物體和值物件、時序圖、資料庫設計等等；

領域服務、領域事件

時序圖

物體關系圖

7、有什么方法能做的更好？

學習和使用領域驅動設計，使用正確的方法梳理和理解業務，并落實到架構程序；

盡早的介入，從業務領域建模和在產品方案階段介入、推動領域知識的傳遞、為后續做好鋪墊；

積累業務能力和洞察力，需要識別關鍵部分與輔助部分、預料可擴展部分與不變部分，識別水平能力與垂直擴展；

對于架構設計產物，不要只畫圖，多輔以文字表述圖中內容；

8、還需要掌握什么知識？

業務知識：業務架構（是對當前業務、領域、能力、流程、參與者、場景的介紹），現狀架構（是對當前架構的描述，可以包含應用架構、技術架構、部署架構、資料架構等），愿景架構（ 是架構應該演進到的完美情況），存在問題（現在面對的痛點、無用部分、缺陷部分）

高性能：多執行緒、佇列、快取、分片、異步化，前置化、靜態化、預處理；

高可用：限流、降級、冗余、災備、回滾、灰度；

擴展性：多型、防腐，依賴反轉（業務身份、擴展點、SPI），抽象化（比如流程引擎、規則引擎等）、事件驅動、設計模式；

本文部分圖片來源于互聯網

作者：京東科技 董健

來源：京東云開發者社區

標籤：其他

上一篇：AI人工智能領域精美繪圖模板分享

下一篇：返回列表