架構
設計，一直就是
軟體業界中顯得高深的名詞之一，會造成很多的人對於它都充滿了神秘感，但接觸過幾年軟體業的人很多時候又會覺得
軟體架構
原來不過如此，特別是看到一些架構設計文件後更是得出如此的感想，但真的是如此嗎？也許是因為那些架構設計文件並沒有起到它們真正的作用，只是拿來糊糊人的吧，架構設計文件最重要的是要能對系統的軟體設計做出指導，做出規範性的約束，不談這些，重點還是談架構設計。
首先我們想想為什麼要做架構設計呢？可能很多人會說在他們的系統中就是沒做架構設計的，但其實不管你有沒有做架構設計，你的腦海中或多或少都是已經考慮過的，只是也許沒有變的那麼的正規，首先，我們來看看什麼是架構，架構作為系統的骨架而存在，正因為這個原因才說所有的系統都是有架構的，有架構自然就有設計，儘管它也許只是浮在你腦海中的某個東西而已，從架構中我們可以看到對於整個系統的支援，包括系統的各個方面，業務
需求、使用者需求以及功能需求的滿足，架構設計能幫助你站在高的角度來看待、分析整個系統，在架構設計中通常採用
ooad
的方法來幫助完成架構設計，想想沒有架構設計的系統是什麼系統呢？是乙個沒有骨架的系統，乙個人沒有骨架會怎麼樣呢？那麼，同樣，乙個系統呢？乙個系統沒有骨架甚至比乙個人沒有骨架更為嚴重。
那麼我們怎麼去做架構設計呢？架構**於需求，是在對需求進行分析、設計的情況下產生出來的，乙個系統的需求通常非常的複雜，那麼怎麼樣去產生它的架構呢？我們知道軟體設計中最重要的就是抽象，其實說的更為專業應該是採用
oo的思想，在過去採用的是面向過程的思想，這裡就不再去討論為什麼要採用oo了，oo中幾個重要的思想就是抽象、繼承、封裝，在分析和設計時我們同樣要進行遵循，分析過程是對需求進行分析，產生出
概念模型
，此概念模型和設計的模型是不同的，概念模型停留於業務層面，而
設計模型
則為對此概念模型提出技術級別的解決實現方案，在經歷了分析、設計過程後我們的系統架構就得以誕生，系統架構作為系統的一部分，同樣要面臨需求變化所帶來的影響，而同時系統架構作為系統最為基礎的部分，是要儘量減少變化所帶來的影響的，要解決這個矛盾，在做架構設計時就要多多的考慮，可以採用使用
模式、介面化等多種方式。
大家也許也看出，在寫這篇blog我表達的並不是很清楚，確實，因為我自己都還有不少迷惑的地方，雖然寫過那麼幾篇架構設計文件，做過那麼幾次架構設計，但一直以來就覺得以前做的架構設計不是那麼的到位，通常有些部分還是平白無故就誕生出來了，而這些主要是依據的自己的經驗，而不是對需求的分析，這對於系統架構而言是致命的，覺得現在也是靜下心來好好考慮的時候了，同時也會多多的參看架構設計理論方面的書籍，結合實踐提公升自己在架構設計上的水平，所以將這篇blog的標題定位了思考之一，在思考的有些進展的時候會將這個繼續的寫下去，也希望能得到更多的做過架構設計的同仁、前輩的指點。
軟體架構設計 一 軟體架構設計過程
軟體架構設計尚沒有萬靈的方 支援，還是個非常新興的行業，給出個人理解的行業軟體架構設計過程，受個人水平有限，僅供參考 1.業務分析 針對目標行業的業務戰略 藍圖 業務功能及流程進行分析，提出其中部分功能可以使用資訊化進行處理，通過分析可以得出資訊化要解決的問題。2.解決方案設計 根據業務戰略，形成行...
軟體架構設計
首先我們應該了解什麼是軟體架構設計？架構大體分為以下幾種 邏輯架構 模組劃分 介面定義 領域模型 開發架構 技術選型 檔案劃分 編譯關係 物理架構 硬體分布 軟體部署 方案優化 執行架構 技術選型 控制流劃分 同步關係 資料架構 技術選型 儲存格式 資料分布 程式設計師向架構師轉型的關鍵突破 學會系...
軟體架構設計
在嵌入式軟體開發的專案中，很少見到有專案架構師這一工作職稱，但是大型專案的總是會有架構師一說。1 為什麼嵌入式開發很少會出現架構師這一職責。嵌入式開發的專案，一般有兩種模式 一類是 完全由開發人員自己設計 排除庫函式 另一類是基於固有的作業系統進行開發。前者一般都是針對特定應用，所有 的規模不會很大...