狹義上的架構設計過程就是“分+合”的過程，一個系統=架構元素+架構+整合機制。那麼怎麼切，依據什麼切？切了以後怎麼往一起整合？我們這裏做個簡單的介紹。
架構設計大的步驟：理清楚要建設的系統的環境上下文要求和需求、梳理出關鍵核心問題、根據核心問題定義邊界、根據邊界切分架構元素（子系統、模塊、服務、類）、定義架構元素之間的交互機制。一共5個步驟，按照這5個步驟進行分析設計，我們基本上可以做到八九不離十。下邊我們逐個講解每個步驟。
第1步：理清楚要建設的系統的環境上下文要求和需求，這一步講究“全面性”，這一步需要架構師有“系統思考”的能力，從空間和時間上對整個系統有個全面的理解。我們之前很多項目出現延期、推倒重來、設計不合理等問題，最重要的原因之一就是獲得的需求不夠全面；很多時候，架構師和開發會把注意力完全放在需求文檔上。作爲某個模塊和功能點的開發人員，這個可能就夠了，但是如果是架構師就遠遠不夠。因爲這些系統環境上下文要求和需求都是下邊第2步裏“關鍵核心問題”的來源。如果環境上下文要求和需求收集地不夠全面，可能影響到“關鍵核心問題”的梳理，最終影響到架構設計。環境上下文要求包括以下內容： 客戶系統部署環境要求：比如說客戶的特殊機房、網絡安全機制要求，這些會影響架構中關於通訊機制的部分和物理部署；再比如說我們需要建設的系統需要和客戶已有的系統進行整合，使用同一套用戶體系，這個會影響到我們用戶註冊、授權、鑑權機制； 客戶工期的要求：1）如果工期要求短，我們可能就需要設計出相對簡單易於實現的架構。2）爲了加快工期，團隊可能需要投入大量的研發資源，因此我們在切分架構的子系統、模塊、服務的時候就要保證適合大軍團並行作戰，各自互不影響，而且他們所負責的聯調、整合機制要簡單、高效。而不能讓模塊之間界限不清，耦合複雜，這樣研發任務也不好切分，形成瓶頸，即使有資源也難以介入；3）這個架構要讓研發流程的後續環節提前介入，並行進行，比如說可以讓測試儘早介入，縮短後續環節的流程，這就要求保證設計的架構要可以做到針對架構元素這種細顆粒度的“可測試性”，比如針對某個組件或者服務進行測試； 分期上線的要求：架構師要有全局視野，是屬於團隊中那個需要擡頭看路的人。因此，務必要關注客戶的短期建設目標和長期建設目標。比如說用戶第一期先上PC端的建設工程，二期再上PC端的政府採購，三期再上建設工程和政府採購的APP項目。那麼這個時候，我們至少考慮：1）二期上線的政府採購不要影響一期的建設工程項目，比如說不要影響已上線系統的舊數據，這個時候我們可能就要讓一期和二期的系統作爲獨立的子系統，可以獨立部署，各自是各自的數據庫。同時，爲了提高用戶體驗，不能讓用戶註冊兩套賬號，分別登陸兩個系統進行工作。所以要提前想好整合方案，比如SSO等等；2）我們需要精心設計後端邊緣服務，保證一套邊緣服務可以同時支持PC端和APP端，而不是開發兩套邊緣服務。因爲兩套邊緣服務不但帶來額外的開發工作量，隨之而來會引入測試、運維的額外工作。也就是說，在分析和設計架構的時候，不要過於計較一城一池之得失的短期利益，而是要全局利益最大化。當然了，這個需要架構師根據具體問題去平衡，基本指導原則是死的，架構師是活的，審時度勢和平衡就是架構師的本職工作和價值之所在； 規避風險要求：風險是相對的，不可能沒有風險，在架構設計過程中規避風險也是需要重點考慮的問題之一。比如：1）技術風險，我們對新技術的都需要一個循序漸進的過程，對於新的技術帶來的風險，我們需要有預備方案，從架構的角度來講，需要有規避機制。比如說我們引入一種新的通信機制，那麼我們就需要抽提出接口組件、基於具體通訊機制的實現組件，保證系統的其他部分依賴於接口組件，而不關心具體的實現組件。保證這個實現組件可替換、可以獨立研發。這樣就可以讓技術好的研發人員集中攻關，而且一旦失敗可以有替換方案補位。2）人員風險，如果團隊中頂尖研發人員分佈不夠均勻，可以通過架構切分，把一些複雜度集中在某些模塊，以此來降低其他模塊的複雜性。相反，如果團隊中實力較強的研發人員分佈比較均勻，架構設計的時候就可以把複雜性稀釋到每個模塊，防止局部複雜性出現，因爲複雜性過於集中，就會形成“高地”，會增加對研發人員能力的要求，這樣往往會成爲瓶頸。 任務計劃要求：系統的功能一般都會有主次先後，在拆分和排布任務的時候，一些核心的任務，比如說和其他模塊交互比較多的模塊、或者其他模塊都必須依賴的模塊、有風險的模塊都是需要放在任務計劃比較靠前的位置，以減少研發進度“瓶頸”的出現，或者“風險前移”。另外，要根據任務的難易程度進行切分，以配合團隊人員能力層次結構進行任務分配。 聯調和測試要求：有的模塊需要調用第三方服務，比如說和第三方的軟件硬件對接。而且這個硬件有特殊的部署環境要求，我們需要去現場聯調。我們就需要把這部分聯調的工作單獨抽取成子系統、組件、服務。這個組件不需要關心其他的核心業務，也可以交給專人處理。這樣測試和聯調起來很簡單、而且每次聯調不需要帶其依賴該功能的相關人員去現場。只要把負責這個模塊的人派過去，只關心這部分功能的聯調。如此就能節約聯調和測試資源，提高效率。而且往往一個架構元素不可單獨測試，可能邊界劃分就存在問題； 功能性需求：這裏就不多做說明，架構師需要注意輔助產品經理和需求梳理出一些隱藏需求就可以了；非功能需求：比如界面美觀程度、相應速度、可伸縮性、可用性、魯棒性、安全性、容災能力、可擴展性、可監控性、可維護性等等，這裏不做贅述，大家可以根據每個系統的要求作出全面評估和考慮。
第2步：梳理關鍵核心問題，這一步架構師需要經過“平衡”，緊抓”主要矛盾“，而不是“鬍子眉毛一把抓”。架構關注的是主要的、核心的、對整體影響較大的問題，比如說：某幾個功能可以拼成一個系統單獨運行和出售、比如說場地系統裏的“門禁卡”功能需要支持對接多家廠商、比如說客戶已經有了用戶中心，我們的系統需要和這個用戶中心進行整合......這些都是可能決定系統成敗的因素，或者說是一旦出問題，影響面非常大的問題。架構不關心那些瑣碎的、局部的、影響比較小問題，比如說某個按鈕的展示風格、完成某個功能需要幾次請求、某個功能的實現需要分解成幾個函數......這種問題即使搞砸了，也不會波及到其他功能從而動搖系統的根本機制。架構師需要從第1步所收集的問題中，萃取和分離出核心的問題。 另外這裏注意的是，這些問題拿來後不是直接就作爲第3步的輸入。有的問題可能需要通過分解、抽提、映射轉換、合併同類項等辦法剝離出真正的問題，甚至會返回去影響需求的重新設計。經過這些步驟後再進行第3步的工作。比如我們會挖掘出一些隱性的需求和問題，而這些問題可能只靠需求人員或者產品經理無法分析出來，比如因爲特殊的部署環境要求，爲了提高部署效率，需要開發出一個部署系統。再比如說，競價系統本身是一個獨立的系統，但是某一天業務提出這樣一個需求：如果沒有人蔘與競價，默認指定第一個繳納保證金的人爲競得人。如果說我們不加分析，直接去實現就會發現，競價系統的邊界被破壞了，競價系統需要依賴保證金系統的服務去獲取第一個繳納保證金的人的數據。如果我們就此引入對保證金的依賴，天長日久，競價系統將變成一堆異常複雜，難以複用的垃圾。經過和需求一起分析後，我們立足於競價系統的概念邊界，提出一個新的概念叫做：默認競得人。業務系統每次推送數據的時候，只需要把默認競得人的數據推過來就行了。這樣我們做到了“一石二鳥”，保證了競價系統的獨立性、豐富了競價系統的概念和功能。這一步需要考驗架構師的“深度思考能力”、“抽象思維能力“。
第3步：根據問題定義邊界； 邊界的定義，就是定義切分的維度，這個維度就從第2步中梳理出來的關鍵問題入手。比如說：要解決場地系統和多家門禁廠商的支持。我們就需要按照這個問題劃邊界。切分成兩個部分，一個是門禁的接口組件、一個是門禁的實現組件。接口組件被其他業務功能依賴，其他功能不關心底層用的門禁技術到底是哪家。門禁實現組件，會有多個，按照每家廠商一個實現組件來切分，這樣我們就形成了一個門禁適配組件集。客戶採購了哪家廠商的門禁產品，我們就把對應的門禁實現組件加入到系統中。這樣，我們可能把研發、聯調、測試的時間都省去了。而且，隨後要接入新的廠商，我們只需要針對這個廠商開發一個新的組件就行了，而且不影響之前已有的組件，哪些組件不需要再測試，聯調一遍。這一步需要考察架構師的“抽象思維能力”和對“面向對象設計原則”的理解能力，比如這個例子就使用了“依賴導致原則”、”開閉口原則“。
第4步：根據邊界切分架構元素（子系統、模塊、服務）；邊界切分的元素到底是採用子系統、模塊、服務哪種呢？這個仍然要根據邊界而定，這個邊界是要解決的問題屬於哪個顆粒度。比如：某些功能點要支持單獨售賣和部署，這個時候切分的邊界就是系統級邊界，就要先採用子系統切分的機制；如果這個功能需要支持多加門禁廠商，這個時候按照組件進行切分就可以了；如果我們要解決某個功能點的橫向擴展能力，支持高併發訪問，這樣就需要切分成單獨的微服務；這個視具體問題而定，不一而足。這一步需要架構師對業務和技術都有較深的功底，能夠針對不同的要求匹配出合適的技術。
第5步：定義架構元素之間的交互機制；切分好後需要將各個架構元素整合在一起，這樣才能完成一些完整的、有意義的業務。比如說系統之間可以採用Web Service、分佈式消息、微服務、數據庫、分佈式緩存來作爲交互的機制。而系統之內的組件之間，則可以採用普通服務接口的方式進行解決，而沒有必要採用更加複雜和“高大上”的微服務。如果是類和類之間，採用Spring這種Bean管理容器就可以解決。這一步要考察的能力和第4步是一樣的。 根據以上的步驟，我們由粗到細、層層遞進，就像推理數學題一樣把框架推理出來，保證每一個決定和步驟都有據可循，而不是憑經驗、憑本能、毫無根據地拍腦袋拍出來。