領域建模
分析的另一種重要產品是領域模型，其目標是使負責該系統基本行爲的所有核心類可視。
軟件的核心是它爲用戶解決領域相關問題的能力。
模型的選擇會影響最終產生的系統的靈活性和可重用性。
由內而外早就軟件。忽視了領域模型這個“內”，而僅重視編寫程序這個“外”，多半是要出問題的。在對象開發過程中一個很重要的原則就是：要設計軟件，使得軟件的結構反映問題的結構。模型的選擇會影響最終產生的系統的靈活性和可重用性。領域模型是對實際問題領域的抽象表示，它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。類圖無疑是領域模型中使用最多的UML圖，但有時狀態圖可以用來對業務領域對象的狀態變化進行有效的補充說明。領域建模是公認的促使OO項目成功的最佳實踐之一。
需求分析的兩個困難：
1、 用戶的參與不夠，造成需求分析成果中假設的成分太多；
2、 問題領域太複雜時，需求分析的開展會遇到困難。
爲解決上述兩個困難，除了運用原型等方法進行需求啓發之外，我們還有必要和用戶進行“更一級”的溝通。領域模型是對實際問題領域的抽象，它“穿透”用戶想要的功能表象，專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。因此，開發方和用戶在“領域模型”上達成的共識，往往比在“功能需求”上達成的共識“更深一級”，從而也更加穩固。“用戶參與不夠”其實是兩個問題：用戶參與不夠多，或者用戶參與不夠深入。（筆者同意上述觀點，但與用戶在領域模型上達成共識，可謂可遇不可求，因爲這需要用戶在有一定的技術背景，並且是很資深的業務專家，因爲領域模型畢竟已經是一種抽象）。用戶代表或領域專家深入參與領域建模活動，可以避免需求分析員對業務領域的理解一直停留在假設的層面，直到軟件開發出來後才被用戶發現的尷尬局面出現。另外，領域建模對需求分析起着必要的支持作用。
領域模型是探索問題領域的工具，可以幫助我們探索和提煉問題領域知識。領域建模和需求分析活動是相互伴隨、相互支持的。領域建模提供的詞彙表應當成爲所有團隊成員所使用語言的核心，在需求活動以及其他活動中起到與團隊交流基礎的作用。另一方面，需求捕獲和分析非常關鍵，因爲不知道客戶想要什麼，就無法提供讓客戶滿意的軟件。
領域模型爲需求定義提供了領域知識和領域詞彙。軟件界面的設計往往和領域模型關係密切，領域信息是所要展現內容中最重要的部分，界面結構必須和業務內容的結構相一致。領域模型是否合理將嚴重影響軟件系統的可擴展性，模型的選擇會影響最終產生的系統的靈活性和可重用性。領域模型經過精化之後會成爲業務層的核心。領域模型是設計持久化數據模型的良好基礎，在實踐中直接將領域模型映射成物理數據模型的例子也屢見不鮮。（在筆者的經驗中，如果項目中使用了全自動的ORMapping框架，如Hibernate，那麼直接將領域模型映射爲物理數據模型，是方便的。但如果是使用半自動的ORMapping框架，如iBatis，或純手工的JDBC或Spring的JDBC Template，那麼還是需要在領域模型與物理數據模型之間多引入一個數據對象，由其隔離物理數據模型的變更對領域模型的衝擊）
《人月神話》一書指出了軟件開發的“根本問題”，首當其衝的就是“軟件的複雜性”。而運用面向對象的領域模型技術，可以幫助我們減輕複雜性的問題。領域模型本身將注意力始終保持在最爲重要的業務概念及其關係上，使我們能夠不斷深入地、系統地整理對問題的認識。領域建模活動的結果是領域模型，但是由於問題領域的複雜性，領域模型不是一蹴而就的。在領域建模過程中，前期的成果往往很不完善，我們會不斷基於現有的成果進行討論、分析和完善。因此，領域建模的過程就是探索複雜問題的過程，而領域模型的早期版本本身也成了促進進一步思維的工具。領域模型決定了軟件系統功能的範圍。任何模型都是對現實世界的某種程度的抽象，領域模型也不例外。抽象意味着有目的性地忽略；而忽略哪些對象關係，保留哪些對象和關係，都和具體目的有關。領域模型還影響着軟件系統的可擴展性。功能是軟件系統能夠完成的具體任務；而模型揭示了豐富多彩的功能需求背後的結構，是我們設法“馴服”複雜性時有了切中要害的“着力點”。功能需求記錄了系統外在的、用戶可感知的“應用列表”，但它們是易變的，當商業環境急劇變化的時候需求尤其易變；而領域模型揭示並模擬問題領域的內部結構，相當於對問題領域進行了一層抽象，良好的領域模型不僅支持現有功能需求的滿足，還在一定程度上支持未來可能出現的新需求。
團隊開發最重要的問題有三個：交流、交流，還是交流。而領域模型是團隊交流的基礎，是所有團隊成員所使用語言的核心。領域模型規定了重要的領域詞彙表，並且這些詞彙的定義是嚴格的、大家共同認可的，所以可以成爲團隊交流的基礎。
確定對軟件架構關鍵的需求
功能、質量和商業需求的某個集合“塑造”了架構。我們把這些塑造需求稱爲“架構驅動因素”。我們的策略是：在架構設計期間，關鍵需求決定架構，其餘需求驗證架構。“關鍵需求決定架構”和“全面認識需求”的策略是不矛盾的。
架構並不是靜態的功能，因此無法優化至最佳——無論是設計約束，還是棘手問題，都不會長時間不變而“等”你找到最佳方案。架構不是要完美，而是要足夠滿意。
把所有需求統統確定下來之後再開始下游活動是不現實的。需求來自於實踐的需要，而實踐是發展的，所以“確定的需求”只能是暫時的。另外，項目何時交付往往是有客戶業務的需要決定的，或者是由市場形勢決定的，這使得項目工期成了不可改變的“外部限制”。所以，我們需要將有限的精力投入到深入分析最爲重要的需求。因爲需求是“促成設計決策的因素”，因此需求的變更可能會引起架構設計不再適合。無論對於概念性架構的設計還是實際架構的設計，都需要對關鍵用例進行分析。回到軟件架構的定義，所謂軟件架構就是關於如何構建軟件的一些最重要的設計決策，這些決策往往是圍繞將系統分爲哪些部分、各部分之間如何交互展開的。要達到高質量屬性的要求，是有成本的。例如，持續可用性的成本最爲明顯，它往往要求通過硬件及網絡鏈接的冗餘來實現，使成本投入非常客觀。商業需求指“組織或客戶高層次的目標”。但作爲“架構設計驅動因素”的商業需求有着更寬泛的含義：它關注從客戶羣、企業現狀、未來發展、預算、立項、開發、運營、維護在內的整個軟件生命週期涉及的商業因素，包括了商業層面的目標、期望和限制等。
概念性架構設計
功能、質量和商業需求的某個集合塑造了架構。軟件系統的概念性架構設計旨在規劃關鍵問題的解決策略。
概念性架構設計的關鍵步驟：
1、 魯棒性分析：通過分析用例規約中的事件流，識別出實際用例規約的功能所需的主要對象及其職責，形成以職責爲主的初步設計。
2、 引入架構模式：架構模式也稱爲架構風格，是軟件界長期實踐的經驗結晶。架構模型的核心是架構機制，即以“架構模型=組件+連接器”的形式明確關鍵設計元素和關鍵交互方式。
3、 質量屬性分享：質量屬性分析給軟件架構師提供了明確的機會去思考和解決這一問題，有利於提升軟件設計質量。
魯棒性分析產生的職責模型是引入架構模式、進行質量屬性分析的基礎，並在這一過程中被調整、被細化，也被組織得更有規律。引入架構模式是爲了確定關鍵的交互機制，而質量屬性分析將針對質量需求制定相關設計決策。
從用例規約向設計概念過渡之所以困難是因爲，第一，用例是面向問題域的，設計是面向機器域的，這兩個“空間”之間存在映射；第二，用例技術本身不是面向對象的，而設計應該是面向對象的，這是兩種不同的思維方式；第三，用例規約採用自然語言描述，而設計採用形式化的模型描述。
邊界對象對模擬外部環境和未來系統之間的交互進行建模。控制對象對行爲進行封裝，描述用例中事件流的控制行爲。實體對象對需要存儲的信息進行描述，它往往來自領域概念，和領域模型中的對象有良好的對應關係。
對象的三類職責：交互、控制、信息。就面向對象系統而言，一個場景的“產生”是一連串的對象協作的“結果”，通過分析場景可以發現這些對象。模型關注職責的劃分，而無論是交互、控制，還是信息維度的職責，都是和具體實現技術這一維是獨立的（或者稱正交的）。
所謂軟件架構就是關於如何構建軟件的一些最重要的設計決策，這些決策往往是圍繞將系統分爲哪些部分、各部分之間如何交互展開的。架構模式描述了軟件系統基本的結構化組織方案。具體而言，架構模式提供了一套預定義的子系統，並規定了子系統的職責，以及子系統間關係的組織原裝和組織指南。分層架構的最大優點是將整體問題局部化，把可能的變化分別封裝在不同的層中，系統被規劃爲一個單向依賴的分層體現，利於修改、擴展和替換。如果說任何一種架構模式都關注職責劃分和交互機制這兩方面的話，那麼我們常說的“分層架構”往往只關注職責劃分。微內核架構“生來”就是爲了適應變化的。爲此，微內核架構不僅將應用相關部分與通用部分分離，而且又將通過部分進一步分離成一個最小化的基本服務內核和衆多擴展內核。
概念性架構應該爲系統的關鍵設計目標負責，對規模很大的軟件系統非常有意義。
質量屬性分析
忽略包括質量屬性需求在內的非功能需求是很要命的。
軟件質量屬性可以分爲運行期質量屬性和開發期質量屬性兩大類。各類需求對架構設計的影響不同，不同質量屬性對架構也要求各異。衆多質量屬性需求之間往往會有衝突，我們必須權衡。質量屬性分析是概念性架構設計的重要步驟。概念性架構包括一些高層次的設計選擇，對未來軟件系統的質量和功能都起着關鍵作用。“確定關鍵需求”活動會甄選出包含關鍵的功能需求、關鍵的質量屬性要求，以及商業層面的目標和限制在內的一個需求子集。在概念性架構設計時，功能需求是魯棒性分析最主要的輸入，而質量屬性需求是質量屬性分析的最主要的輸入。所謂質量性分析，是軟件架構師對軟性系統要達到的質量屬性需求進行分析、制定相應軟件架構設計決策的過程。“屬性—場景—決策”方法提倡通過一組具體場景將要達到的質量屬性需求目標細化。
“可測試的需求”是發展方向。“將質量屬性需求細化爲一組質量場景”這一方法，發現實施它的最佳時機是需求分析期間，而不是架構設計之時——即《需求文檔》應將質量屬性需求細化到一組具體的場景。
