本文地址：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专家们建议任何对通用语言进行更改都要在模型中同步更改。如果你让模型偏离了业务域，你有效地生成一个映射到模型和域的中间语言--从长远来看这是在拼写灾难。你会生成一个特殊的人物类，它能解释这两种语言，然后他们会通过对这两种语言的不完整理解来过滤需求。