本文地址：http://www.cnblogs.com/outtamyhead/archive/2013/04/25/3041809.html，轉載需保留本地址。
說在前面：
1、由於是頭次翻譯整本書籍，所以錯誤難免，希望大家都提出來，翻譯的不好還望大家少拍磚多鼓勵。
2、該系列沒有按照原文直譯，而是加入了我的一些言語在里面（在沒有改變原意的情況下），所以大家在看的時候希望有所對照。
3、該系列每周出一或二篇博客，因為我最近很忙，一直在加班，很累的說。
4、該系列不提供原版文字，希望看原版的可以自行下載Pdf。
5、該系列省去了前面的廢話，單刀直入，講主體內容。
出差了一個多星期，現在終於安定下來了。
應用域驅動開發
我們已經描述了在你的應用程序中一個域模型如何反映真實的世界，包括對象，過程和規則。域模型是MVC應用程序的核心--其他的，包括視圖和控制器，僅僅是與域模型進行交互的方法。
ASP.NET MVC並不指定域模型要使用的技術。你可以自由的選擇任何一種技術來與.NET Framework進行交互--這有很多選擇。當然，ASP.NET MVC給我們提供了基礎體系結構和約定來幫助我們實現域模型中的類與控制器、視圖之間以及MVC框架本身的聯系。這包含三大關鍵特性：
模型綁定是一個基於約定的特性，它用輸入數據來自動的形成模型對象，通常是來自HTML表單提交。
模型元數據讓你把模型的含義描述給框架。例如，你可以給他們的屬性提供一個易讀的描述或者給出一個它們如何顯示的提示。MVC框架隨后就可以自動的為你的模型類渲染一個顯示或者一個編輯頁面到你的視圖中。
驗證，在模型綁定時執行並且添加的規則可以被定義為元數據。
在第二章我們建立我們的第一個MVC應用程序時我們簡要的接觸了模型綁定和驗證--我們將回到這些主題並在第22和23章研究這些功能。現在，我們打算把MVC的實現放在一邊，轉而考慮域模擬自己的一個活動。我們打算通過使用.NET和SQL Server創建一個簡單的域模型，使用一些domain-driven-development（DDD）的核心技術。
模擬一個示例域
你可能經歷過關於域模型討論的頭腦風暴。它通常包括開發者，業務專家，大量的咖啡，點心和白板筆。之后，房間里的人統一於一個共同的理解然后形成了域模型的初級形態。你的最后結果可能和圖3-5相似，這就是這個示例的起點--拍賣應用程序的一個簡單的域模型。
這個模型包括一組成員，每一個成員都包含一組報價。每一個報價都對應一個商品，然后每一個商品都有來自不同成員的多個報價。
通用語言
把你的域模型當成特定組件實現的一個關鍵好處是你可以采用你選擇的語言和術語來實現。你應該試着找出對象，操作和關系的術語，它不僅對開發者有意義，而且對你的業務專家也是一樣。我們建議你當域已經存在時采用域術語當--例如，如果一個開發者提到Users和Roles，它們會被理解成域里面的agents和clearances。我們建議你在域模型中采用后者。而當模擬那些域專家還沒有術語的概念時，你們應該對如何引用它們達成一致，生成一個在整個域模型當中通用的語言。
開發者傾向於代碼語言的叫法--類的名稱，數據庫表等。業務專家則不用理解這些--也不必理解這些。一個有一些技術知識的業務專家是一個危險的東西，因為他會通過他自己對技術的理解不斷的過濾他的要求，當這一切發生，你不會真正領會業務需求是什么樣的。
這種方法還有助於在應用程序中避免過度概括。程序員傾向於模擬每一個可能的業務事實，而不是業務需求的特定情況。在這個拍賣模型中，我們也許會最終以關系連接的資源的一般概念來代替成員（members）和商品（items）。當我們創建一個並不與要模擬的模型相匹配的域模型時，我們就失去了獲取業務過程實際情形的任何機會--並且，進一步的，
我們最終會把事務過程的變化以優雅但過於抽象的元世界表示為難以使用的案例。約束並不是限制，而是指導開發沿着正確的方向前進的視點。
通用語言與域模型之間的關聯並不是表面的---DDD專家們建議任何對通用語言進行更改都要在模型中同步更改。如果你讓模型偏離了業務域，你有效地生成一個映射到模型和域的中間語言--從長遠來看這是在拼寫災難。你會生成一個特殊的人物類，它能解釋這兩種語言，然后他們會通過對這兩種語言的不完整理解來過濾需求。