如果有人讓你介紹你們做的系統架構是什么樣子的 你會從哪說起？
每個人都會有自己的架構認知，根據自己的接觸的內容來總結。系統分為用戶中心、營銷中心、商品中心…… 這是產品經理說的；我們的系統用了三層架構，用了SSM框架…… 這是程序員說的；用戶說 我們系統有后台，前台，商品上下架功能，用戶管理功能。
在實際工作中架構師架構出來的系統不僅要考慮用戶的功能實現，而且也要平衡系統的易用性、高性能、擴展性、可伸縮性等方面，這里面是要綜合業務目標、當前開發人數、開發人員的綜合能力、上線時間、項目預算等來選擇開發語言、開發框架和功能開發的順序。有些公司求時間、有些公司求質量，但最終說明架構是實時變化的，不是一上來就來個完美的架構，是要根據當前的業務需求變化的，但你的架構必須要支持這種變化 達到上面所說的要求。
一個復雜的系統需要不同角色的人來參與，因此架構師必須考慮到讓不同的參與者理解你的架構 知道他們自己該做什么事，如用戶為你提供原始需求，項目經理需要制定計划 在不同小組間溝通 落地你的架構，開發人員拿到你的設計實現功能。所以架構涵蓋的內容和決策太多了，需要從不同視角分別設計 ，也是為了架構方便理解、交流和歸檔的方便。
最常用的架構分為：邏輯架構和物理架構視圖
邏輯架構
邏輯架構規定了由哪些邏輯元素組成以及這些邏輯元素間的關系，邏輯元素可以是邏輯層、功能子系統、模塊。
物理架構
展示模塊間的部署邏輯，數據如何產生、哪塊計算、怎么存儲、共享等在計算機中的情況。
這里暫時先列出概念，架構設計之初避免涉及太多具體的技術細節，需要看透需求，尋找出實現的難點、以質量還是時間優先。
5視圖法：邏輯架構、物理架構、數據架構、開發架構、運行架構
面對不同的角色需要用不同的思維來表達，對領導匯報用業務圖而不能講技術架構，對開發則可講具體開發架構，對運維講運行架構、物理架構，因此需要不同的架構設計來表達。
邏輯架構
邏輯架構= 模塊划分+接口定義（統一接口規范）+領域模型
物理架構
物理架構=硬件分布+軟件部署+方案優化（可伸縮性、高性能、易維護性，監控）
物理架構，更關注的系統、網絡、服務器等基礎設施。例如：如何通過服務器部署和配置網絡環境，來實現應用程序的“可伸縮性、高可用性”。或者舉一個實際的例子，如何通過設計基礎設施的架構，來保障網站能支持同時10W人在線、7*24小時提供服務，當超過10W人或者低於10W人在線時，可以很方便的調整部署架構來支撐。
數據架構
數據架構=存儲方式+數據分布
數據架構，更關注的是數據持久化和存儲層面的問題，也可能會包括數據的分布、復制、同步等問題。更貼切來講，如何選擇需要的關系型數據庫、流行的NOSQL，如何保障數據存儲層面的性能、高可用性、災備等等。很多時候，和物理架構是有緊密聯系的，但它更關注數據存儲層面的，物理架構更關注整個基礎設施部署層面。
開發架構
開發架構=技術選型+文件划分+編譯關系（模塊依賴關系）
開發架構則更關注程序包，不僅僅是我們自己寫的程序，還包括應用程序依賴的SDK、第三方類庫、中間價等。尤其是像目前主流的Java、.NET等依靠虛擬機的語言和平台，以及主流的基於數據庫的應用，都會比較關注。和邏輯架構有緊密的關聯。
運行架構
運行架構=物理架構+數據流的控制（系統運行中的數據流向關系）
顧名思義，更關注的是應用程序運行中可能出現的一些問題。例如並發帶來的問題，比較常見的“線程同步”問題、死鎖問題、對象創建和銷毀（生命周期管理）問題等等。開發架構，更關注的是飛機起飛之前的一些准備工作，在靜止狀態下就能規划好做好的，而運行架構，更多考慮的是飛機起飛之后可能發生的一些問題。
實現架構設計的6個步驟：
需求分析
根據系統使用人、客戶等收集而來的業務實現的背景要求組成的原始需求文檔分析，包括了功能要求、質量（性能要求）、約束（時間、預算、可行性分析、風險評估、是否需要對接三方）。這里要輸出一份整理過后的需求文檔，包含了要做什么（功能范圍、非功能性需求），能不能做，能做到的前提要求和要面臨的問題，怎么做（進入系統分析實現階段）。
確定關鍵需求
不僅要對功能需求（如用例）進行篩選，還要對非功能需求進行權衡，最終確定對架構起關鍵作用的需求。如需求是以高性能並發度為關鍵還是以可擴展性為要求或同時滿足，因為考慮到成本、上線時間和現有系統的影響會舍棄一部分需求，需要確定關鍵需求：核心功能、高風險功能。
概念架構設計
1個決定4個選型：決定如何划分頂級子系統；架構風格選型（C/S還是B/S架構）；開發技術選型（java）；集成技術選型（API）；二次開發技術選型（API）。
細化架構設計
5視圖法：分別從邏輯架構、物理架構、數據架構、開發架構、運行架構進行設計，每一塊的關注點不一樣，可細化粗粒度。
領域建模
領域建模的精髓是 業務決定功能，功能決定模型。將需求業務轉化為抽象的模型對象之間的流轉關系。
常用的表達方式是類圖 表達模型之間的關系，聽得最多的是“建模”。模型的建立也是逐步完善的，還包含了狀態（流程圖）、特性要求等文字說明。
關於如何領域建模 有專門的 領域驅動設計 方面的書可以參考。
架構驗證
可快速開發一個統一框架（一個原型、一個技術難點）來貫徹架構的設計，再對原型進行測試評審 再對架構進行補充。
最后可以總結為可以用5視圖法從各方面來描述系統的架構，然后用6步驟來描述怎么實現架構。不過現在還流行一種就是將業務邏輯與物理架構放一起 忽略其中的實現細節。
軟件架構就是實用而且優雅的設計，它不在於分多少層，或者應用了多少種設計模式/架構模式等。它應該是以滿足實現用戶需求為前提，以開發人員普遍可接受為根本的，而且要符合系統特性和業務發展需要的，從軟件設計的角度，能夠達到層次清晰、可維護、可重用、可擴展…就非常優秀了，無需刻意去糾結分了多少層，是否使用了什么模式，有多么抽象等。以面向對象設計為例，基本目標是“高內聚、低耦合”，為此我們可能會遵循一些常見的設計原則（例如經典的SOLID設計原則）。
通常我們所說的模式，其實又分為很多種，並不是僅僅指的是“設計模式”（設計模式也有千千萬，並不是只有常見的GOF 23種設計模式）。通常包括：企業架構模式、設計模式、SOA模式、企業集成模式等等。
強調一下，架構要講求“實用”，而且開發人員普遍可接受，要符合現狀的。否則，再“優雅”的設計，都會淪為高成本的“花架子”，生搬硬套和過度設計只會讓項目“流產”。