Pro ASP.NET MVC 3 Framework学习笔记之四

主题：应用领域驱动开发(Applying Domain-Driven Development)

Domain Model是MVC程序的"心脏"，其他的一切，包括Controllers和Views仅仅是用来跟Domain Model交互的一种方式，ASP.NET MVC并没有限制使用在Domain Model上面的技术，我们可以自由的选择跟.net framework交互的技术，并且这样的选择是非常多的。不仅如此，ASP.NET MVC为我们提供了基础的架构和约定来帮助Domain Model里面的Classes跟Controllers和Views的联系，也包括跟MVC自己的联系。它们有三个关键的功能，如下所示：

a.模型绑定(Model Binding):是自动使用HTML表单提交的数据来组织领域对象(Domain Objects)基础的约定。

b.领域元素据(Model metadata):描述了Model Classes对.net的所要表达的意思。举例而言，就是给属性赋予一个人容易理解的表述或者是对属性呈现时的一些提示。asp.net mvc能够自动的识别并对Model Classes合理的呈现到Views里面。

c.验证(Validation):能够在模型绑定时被执行，并且能够应用被定义为元素据的那些规则。

如果你对于模型绑定(Model Binding)的理解也跟我一样还不是很清楚，也没有必要着急，更不要放弃对MVC的学习，因为书的后面章节会有详细的讲解 ，呵呵。现在我们先将ASP.NET MVC的实现放到一边，单纯思考下领域建模(Domain Modelling)，下面使用.net和sql server创建一个简单的竞拍程序的领域模型。

一，创建一个简单的领域模型

下面是要创建的竞拍程序的类图

上面的模型包含了一个Members的集合，每一个Member会有一个Bids集合，每一个Bid对应一个Item，每一个Item可以有多个来自不同Members的Bids

实现我们自己的domain model并作为一个独立的组件其中一个关键的地方是我们选择的语言和术语，这个不是我们的编程语言，而是领域建模的通用的语言。这种语言是开发人员和领域的专业人员都知道的，这样主要是为了这两种人能流畅的交流，而这却是至关重要的。当领域的专家们不了解建模的一些概念时，我们应该针对使用的术语达成一个共识，这个共识就是创建一种通用的语言并贯穿在整个领域建模过程中。这样做有很多的好处。

1.首先，开发人员倾向于使用编程语言，比如类名，数据库等等名词来表达。而业务专家们是不懂这些的，他们也不需要懂。业务专家知晓一些技术方面的知识是一件非常危险的事情，因为他们会经常根据自己对技术的理解来不断筛选他们的需求，这也就意味着需求会频繁的更改，进而导致开发人员也不知道业务专家的真实需求到底是什么。创建通用语言的方法能够帮助我们避免在一个应用程序里面过度的泛化需求，程序员倾向于建立每一个可能业务实际模型，而不是具体到某一个业务需求。

2.在通用语言和领域模型之间的这种连接不应该是非常肤浅的而是向DDD(Domain-Driven Design)专家所建议的那样：对通用语言的任何变化都会导致Model的变化。假如我们让建模跟业务领域不同步，我们就需要建立一种从Model到domain映射的中间语言，从长远来看，这种做法会导致灾难。为此，我们将创建一个会两种语言的特殊人类，他们随后就开始筛选需求，这却是建立在他们对两种语言都不完全理解的基础之上，当然这样的后果可以想象。

二，聚合与简化

上面的图，为我们提供了一个很好的建模起点

但是上面图示的模型并没有提供用C#和SQL Server实现Model的任何有用的帮助，会有不少的问题困扰我们：

1.如果我们load一个Member进入内存，也是不是应该load Member的Bids以及相关的Items进入内存呢？

2.如果我们这样做了，我们是否需要将这个Item其他的bids也load进内存，并且也将做这些Bids的Members一同load进内存呢？

3.当我们删除一个对象时，我是否应该删除相关的对象呢？如果是，又有哪些呢？

4.如果我们选择用文档存储代替关系型数据库来持久化，那哪一个对象的集合应该呈现到同一个文档呢？

所有以上的问题，我们不知道作何解答，并且我们的领域模型也没有给我们任何答案。

回答这些问题的DDD方式是将Domain Objects分配到组里面，这种方式称为聚合(aggregates)。

下图很好的展示了怎样聚合在我们这个竞拍程序里面的领域模型，如下所示: