1，轉自 百度百科 “MVC模式”：
http://baike.baidu.com/view/739359.htm
2，關鍵需求決定架構
軟件架構師沒有時間對“所有需求”進行深入分析，這是現實——大多數項目都面臨項目工期的壓力，軟件架構師必須在一定的時間內定奪架構設計方案；否則，沒有軟件架構所提供的對技術的足夠指導以及對分工協作的足夠限制，後期的團隊開發將面臨巨大風險。
軟件架構師沒有必要對“所有需求”進行深入分析，這是策略——把大部分時間和精力花在對決定架構最重要的一部分需求上，好鋼用在刀刃上，最終你設計出的軟件架構的質量反而會更高；否則，所有需求的分析都不夠深入，導致最終設計出的軟件架構可能會流於形式。
3，關鍵性的第一步是縮小範圍
PeopleSoft公司的首席技術官Rick Bergquist說得精闢：“我的第一個老闆John Grillos曾說過，要擇戰而鬥。擇戰的標準如下：它們要具有重要性，它們要具有可能性，它們的數量要少。”
4，實踐中的常見問題
問題一：抱怨留給架構設計的時間太短，而不是接受項目節奏普遍加快的現實。
從根本上講，這是沒有意識到軟件開發所根植於的業務背景——當然，我相信或多或少也受到瀑布模型的影響。無論是對於企業業務還是個人業務，在複雜和高速變化的經濟環境裏，在對手雲集的競爭條件下，軟件系統“上馬”太慢本身就潛藏着巨大風險。在《非程序員》第50期中有一篇來自Markus Völter和Jorn Bettin的論文《模型驅動軟件開發模式》，其中強調新的商業應用的開發期最多不得超過9個月：
……
每三個月至少要提供可交付代碼。
理想情況下，每三個月應將代碼部署到產品中，並得到實際反饋。
新的商業應用的開發，必須在九個月之內“哇哇墜地”，否則就可能危及“媽媽”（開發組）或“嬰兒”（應用）的生命……
問題二：認爲必須詳細分析所有的需求，只有這樣才能設計出滿足所有需求的軟件架構。
有仗就打、有人討敵罵陣就出戰，這種情形在歷史小說裏經常見到，但往往出現在有勇無謀的武將身上。與此類似，想要將所面對的所有需求都分析一遍的軟件架構師是否想過：這是否現實？在有限的時間裏，將精力分散在過多的問題上，其結果往往是效果更差。
我們的策略是：關鍵需求決定架構，其餘需求驗證架構。
順着“全面認識需求”的策略思考開去，很容易讓人產生疑問：你是在說瀑布式開發嗎？當然不是。我們的策略是：在架構設計期間，關鍵需求決定架構，其餘需求驗證架構。也就是說，“關鍵需求決定架構”和“全面認識需求”的策略是不矛盾的。
非關鍵需求可以用來驗證架構，比如以架構方案評審的方式，從每項非關鍵需求的角度對架構方案進行走查。
問題三：認爲軟件架構必須是完美的技術解決方案。
關於這一點，Philippe Kruchten在他的論文《Common Misconceptions about Software Architecture》中明確地進行了批評，並指出架構“夠用就好”：
通常，在進行系統架構設計時，時間非常關鍵。架構師根本沒有時間去系統地研究每一種可能的解決方案，以找出最佳解決方案；而是必須快速決策，以便讓軟件開發工作進行下去。項目開發就像一場“戰鬥”，如果慢慢吞吞地研究出了最佳解決方案，只怕整場“戰鬥”早已結束多時了，這顯然毫無意義。我經常這樣描述架構師的工作：在有些事情並未完全清楚的情況下，快速做出一系列並不算完美的設計決策。架構並不是靜態功能，因此無法優化至最佳——無論是設計約束，還是棘手問題，都不會長時間不變而“等”你找到最佳方案。架構不是要完美，而是要足夠滿意。（Usually, time is of the essence when designing system architectures. The architects have no latitude to systematically study all possible solution paths and their combinations in order to come up with the optimal solution; they must rapidly make decisions to allow work to proceed. There is no point in coming up with the ideal solution after the battle is lost. I often describe the life of a software architect as a long and rapid succession of suboptimal design decisions taken partly in the dark. It is not a static function that we are optimizing anyway. Neither the constraints nor any parts of the problem are static enough for long enough to approach anything "optimal". Architecture is not about the optimal, or ideal; it is about the adequate, or satisfactory.）
5，如何確定關鍵需求——需求的優先級
對軟件架構關鍵的需求包括功能需求、質量（屬性）需求、商業需求三類。
所謂對軟件架構關鍵的功能需求，就是它涉及（或串起）的模塊最多、最典型的功能需求。
對架構至關重要的質量屬性需求是那些經過權衡取捨、最終決定重點支持的質量屬性需求。