在軟體設計中架構域是如何劃分的，架構域包括：業務架構、資料架構、產品架構、應用架構、技術架構。在一篇文章中看到關於架構的劃分， 同時應該是崗位或者人的職責劃分。
系統架構師，從系統的維度，負責整體系統的架構設計，主要是基礎服務和各系統間協調上，著眼全域性不太注重某個應用本身架構，比如關注伺服器負載，可靠性，伸縮，擴充套件，資料庫切分，快取應用等方面的基礎架構設計。
業務架構在很多企業其實是boss在做決策時已經定下，後續跟進人員包括業務規劃、業務模組、業務流程，對整個系統的業務進行拆分，對領域模型進行設計，把現實的業務轉化成抽象物件。這中間包含2個重要因素需要考慮：時間和成本。
資料架構很容易想到dba，資料架構需要解決3個問題：1.系統中需要什麼資料（基礎）；2.資料怎麼儲存；3.資料架構設計（與業務實體進行關聯對應）。這3個問題涉及三個部門工作：產品需求調研，dba提供部署資料方案，開發人員設計表結構。
產品架構自然而然是產品經理需要負責的工作，這個架構離使用者最近，從業務要求、使用者使用習慣、人群喜好等設定產品的功能或者互動流程。
技術架構主要針對開發或架構師，根據應用架構來梳理技術需求，再做技術選型，最後把技術和技術之間的關鍵點描述清楚。
技術架構解決的問題包括：如何進行純技術層面的分層、開發框架的選擇、開發語言的選擇、涉及非功能性需求的技術選擇。由於應用架構體系是分層的，那麼對應的技術架構體系自然也是分層的。大的分層有微服務架構分層模型，小的分層則是單個應用的技術分層框架。大的技術體系考慮清楚後，剩下的問題就是根據實際業務場景來選擇具體的技術點。各個技術點的分析、方案選擇，最終形成關鍵技術清單，關鍵技術清單考慮應用架構本身的分層邏輯，最終形成乙個完成的技術架構圖。從上面架構分類來看，前面乙個架構是後面架構的輸入，技術架構是最終產品的實現過程。
在小公司可能沒有這麼多所謂架構，老闆一句話就開始幹活，越快幹完越好，說不定老闆賞乙個「***」。但是在大公司不可能這樣，因為在大公司，人多溝通不方便，必須靠制度來約束。
按照套路來設計架構必不可少，統一的視覺化架構圖，對應的人只需要關注自己職責範圍內的即可。
同時這些也為後來的人提供乙個榜樣，也是一種學習的資源。
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
mysql架構設計 初識mysql架構設計
一 應用系統如何與mysql進行一次互動？最開始接觸jdbc的時候，我們系統如何完成一次sql操作呢？第一步，建立資料庫連線 第二步，操作sql 第三步，釋放連線。但是每次建立與資料庫的連線非常耗時和資源，所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線，第三步的釋放連線不...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...