本篇文章主要分析，架構師在設計系統架構時，應關心哪些關鍵要素？
一 業務場景
a公司是一家服裝公司，主要提供服裝一體化服務(服裝設計，服裝銷售，售後服務等)，該公司主要通過**，天貓，京東等平台進行銷售，由於公司
良好的服裝質量，高效的服務水平和良好的信譽等，使得公司的銷售量不斷地增長，到了第五年，公司的銷售呈現指數型增長....，為了迎合指數型的業務需
求，公司高層決定使用網際網路技術來迎合指數型的業務需求。
該專案由cto全程負責，並向ceo匯報，cto指定小張為該專案業務負責人，小紅為該專案技術負責人，他們兩人定期向cto匯報。其中，cto主要負
責系統的系統架構，專案管理，團隊組建，關鍵業務溝通等工作，小張主要負責業務相關的事，如需求調研，需求文件編寫等，小紅主要負責專案落地開發，
如核心模組開發，及時解決團隊開發出現的技術性問題。
如此，cto做出了如下的業務架構，該專案命名為：線上倉儲系統（onlinewms）
（1）通過線上平台提供的介面，抓取使用者訂單
（2）將抓取的訂單儲存到倉儲系統
（3）將訂單相關資訊傳遞給sap(可以理解為財務系統)
（4）當貨物傳送後，在wms系統上，通過物流介面查詢訂單狀態(傳送，未傳送，已收貨，退貨等)
二 架構師應關心的若干要素
1.明確系統功能(what)
在業務架構中，系統架構師一定要非常了解且明確系統要解決的核心業務，在設計前，建議考慮如下問題：
專案需求是什麼？
專案需求是基於什麼背景下提出的？
專案需求的核心業務是什麼？
專案需求的難點和痛點是什麼？
在充分考慮如上問題後，就是問題答案的尋找和求證過程：
答案尋找？
如上系列問題，均可在需求文件中找到，因為一般情況，需求文件都會有詳細描述，需求文件的**一般經過幾個階段：
需求提出=》需求調研=》需求初稿=》需求評審=》需求修改=》需求定稿
答案求證？
系統架構師在充分研讀需求文件後，對需求基本有所了解，然而這些所謂的了解，是需要與需求提出者，需求撰寫者等關鍵人物確認的
確認的，這個過程也叫答案的求證過程，只有該過程確定後，方可進行下一環節。
2.定義系統邊界(scope)
在充分明確需求後，就要定義系統邊界了，首先來了解一下，什麼叫系統邊界。
系統邊界：指本次專案由哪些系統構成(或子系統構成)。
cto為onlinewms系統定義了四個邊界：線上介面(訂單的**)，物流介面(訂單狀態查詢)，wms系統(訂單管理，衣物儲存等)，sap系統
（財務相關）
很容易看出，這幾個邊界定義還是比較明顯的，職責分工明確，無重疊業務。
3.定義系統之間的互動方式
cto為onlinewms系統定義了四個邊界，且這四個邊界的互動方式是以介面的方式進行的。
4.介面設計規範
關於介面設計規範，請參考我的另一篇文章如何設計乙個良好的介面
5.系統難點
該系統，從線上抓單，且將訂單及時地儲存到wms系統是一大難點和挑戰點，尤其在雙十一，雙十二等高峰時段，成千上萬的高併發量，
10w-1000w的訂單量等都完全有可能導致系統崩潰。然而，該難點卻有很多可以捕捉的特點，歸結如下：
（1）存在高併發量特徵
（2）存在大規模訂單特徵
（3）存在系統響應及時特徵
（4）存在高併發、大規模訂單集中於某個時間段，而非長時間(如1年)特徵
6.業務模組與非業務模組拆分
該系統中，存在業務模組與非業務模組，需要進行拆分，如非業務模組授權管理、日誌記錄等需要從業務中拆分開發來，可以採用aop技術
實現，如spring aop,aspectj等。
7.模組解耦
該系統中，模組之間存在必要的依賴關係，為了盡可能的降低這些依賴關係，可以採用di(依賴注入技術)來解決，如spring框的di。
8.技術選型
涉及到前端框架，後端框架，orm框架等。
在選擇框架時，盡量選擇主流且被廣泛使用的框架，盡量不要選擇不太主流或太新的框架。
在框架組合時，防止過大，也防止過小，如ssh,ssm,springboot+springcloud+redis+mongo+mq+dubbo等，要根據具體的業務場景來選擇。
9.開發團隊
在組建團隊時，要充分考慮風險，如團隊人員突然離職造成專案延誤等風險，建議採用職能組織架構結構來組建團隊。如乙個技術開發經理，2個高階開發，3個中級，4個初級等，
這樣搭配的好處是，當技術開發經理突然離職(一般技術開發經理很少離職)，2個高階開發可以頂替上去；若有乙個高階開發離職，兩個中級可以頂替上去....如此，就算某個人離職，
對專案影響都不會太大。
10.專案管控
管理專案計畫，專案進度，開發團隊人員情緒、處理開發技術問題等。
三 版權區
軟體架構要設計到什麼程度
由於軟體系統的複雜性，一般人很難非常清楚的將整個系統理的很清楚，所以才會出現架構檢視的概念，而架構檢視出現的乙個主要動力或者原則就是 分而治之。分而治之有兩種型別 1.按問題深度分而治之，即先不把問題想的那麼深入，那麼仔細，要淺嘗輒止。例如定義各個模組之間的介面就屬於這種，先不考慮如何實現介面，只是...
軟體架構師應具備的十大特點
4141 軟體架構師 設計模式 開發者軟體開發測試 如果有人問你，作為乙個軟體架構師需要哪些特質的話，你會怎麼回答？從技術層面上講，架構師的技術要求是首位的。除此之外在做人處事方面，更有魅力的架構師則更受歡迎。最近有個同事問我，是什麼成就了乙個架構師。下文就是我的回答，適用於各個技術領域。其中我故意...
架構漫談（六） 軟體架構到底是要解決什麼問題？
前一篇文章簡述了什麼是軟體。那麼什麼是軟體架構呢？按照慣例，我們來看看是什麼問題，是誰的問題。要解決誰的問題？如前所述，軟體實際上就是把現實生活模擬到計算機中，並且軟體是需要在計算機的硬體中執行起來的。要做到這一點需要解決兩個問題 一 業務問題 具體的現實生活狀態下，沒有軟體的時候，所解決的問題的主...