軟體設計師中有一些技術水平較高、經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分、元件之間如何發生相互作用，以及系統中邏輯的、物理的、系統的重要決定的作出。通常在乙個開發小組中，最有經驗的程式設計師會負責一些架構方面的工作。在乙個部門中，最有經驗的專案經理會負責一些架構方面的工作。
個人感覺，架構是最重要的工作，好的架構可以大大減輕後期的工作難度。軟體與人類的關係是架構師必須面對的核心問題，也是自從軟體進入歷史舞台之後就出現的問題。與此類似地，自從有了建築以來，建築與人類的關係就一直是建築設計師必須面對的核心問題。
那麼軟體架構都要完成那些任務呢？一般而言，軟體架構設計要達到如下的目標：
·可靠性（reliable）。軟體系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。
·安全行（secure）。軟體系統所承擔的交易的商業價值極高，系統的安全性非常重要。
·可擴充套件性（scalable）。軟體必須能夠在使用者的使用率、使用者的數目增加很快的情況下，保持合理的效能。只有這樣，才能適應使用者的市場擴充套件得可能性。
·可定製化（customizable）。同樣的一套軟體，可以根據客戶群的不同和市場需求的變化進行調整。
·可擴充套件性（extensible）。在新技術出現的時候，乙個軟體系統應當允許匯入新技術，從而對現有系統進行功能和效能的擴充套件
·可維護性（maintainable）。軟體系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟體需求反映到現有系統中去。乙個易於維護的系統可以有效地降低技術支援的花費
·客戶體驗（customer experience）。軟體系統必須易於使用。
·市場時機（time to market）。軟體使用者要面臨同業競爭，軟體提供商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。
從關注的角度不同架構可以進行分類：
邏輯架構，軟體系統中元件之間的關係，比如使用者介面，資料庫，外部系統介面，商業邏輯元件，等等。
·物理架構，也就是軟體元件是怎樣放到硬體上的。
·系統架構、系統的非功能性特徵，如可擴充套件性、可靠性、強壯性、靈活性、效能等。
首先，乙個軟體系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬體上，以及這些元件如何為整個系統的可擴充套件性、可靠性、強壯性、靈活性、效能等做出貢獻，是非常重要的資訊。
其次，進行軟體設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦作出，就很難更改的。
這讓我想到了之前做的乙個資料庫的專案，乙個基於資料庫的系統架構，有多少個資料表，就會有多少頁的架構設計文件。比如乙個中等的資料庫應用系統通常含有一百個左右的資料表，這樣的乙個系統設計通常需要有一百頁左右的架構設計文件。
開始的架構設計也是最難的，需要調研同類產品的情況以及技術特徵，了解當前世界上對這種產品所能提供的理論支援和技術平台支援。再結合自己專案的特點(需要透徹的系統分析)，才能逐步形成自己專案的架構藍圖。
正如我們學的迭代開發方式一樣，好的設計肯定需要經過反覆修改，從簡單到複雜的迴圈測試是保證設計正確的乙個好辦法，在不斷迭代中逐漸完善整個系統的框架，不要求一開始就設計出十全十美的軟體框架，這對框架設計師來說要求太高。因此，一開始我們不可能將每個需求都實現，而是採取一種簡單完成架構流程的辦法，使用最簡單的需求將整個架構都簡單的完成一遍（加入人工干預），以檢驗各個技術環節是否能協調配合工作(非常優秀先進的兩種技術有時無法在一起工作)，同時也可以探知技術的深淺，掌握專案中的技術難易點。這個過程完成後，我們就對設計方案做出上面的重大修改，豐富完善了設計方案。這樣，我們才能讓軟體框架真正為我們專案的完成起到至關重要的作用。
MVC MVP MVVM 軟體架構的理解
複雜的軟體必須有清晰合理的架構，否則無法開發和維護。mvc mvp mvvm 就是常見的軟體架構模式，屬於程式設計的方 mvc 是 model view controller 的縮寫 較其他模式的特點 model 和 view 之間存在直接的通訊，而這在其他兩種模式中不存在 優點 缺點 mvp 是 ...
軟體架構的定義及其理解
所謂軟體架構，指的是軟體系統的整體結構，包括軟體子元素，這些元素的外部屬性以及元素元素之間的關係。這個定義包含了以下三層意思 1 軟體架構是對系統的抽象。它不僅規定了系統有哪些主要軟體元素或模組，還定義了這些元素之間是如何互動的。它並不暴露每個元素的內部屬性 也叫區域性資訊 也就是說每個子模組的私有...
對軟體架構的一些理解
一說到 架構 這個詞，頓時感覺自己也高大上了不少 架構是個很寬泛的概念，任何專業領域都有自己的架構。軟體行業可分為業務架構 軟體架構 系統架構。業務架構最表層的理解就是對業務模組的粒度劃分。好的業務架構的設計是好的軟體架構的基礎。業務架構要考慮業務粒度的劃分大小，太大，在進行事務管理的時候就會無法區...