前言：又有差不多半个月没写点什么了，感觉这样很对不起自己似的。今天看到一篇博文里面写道：越是忙人越有时间写博客。呵呵，似乎有点道理，博主为了证明自己也是忙人，这不就来学习下DDD这么一个听上去高大上的东西。前面介绍了下MEF和AOP的相关知识，后面打算分享Automapper、仓储模式、WCF等东西的，可是每次准备动手写点什么的时候，就被要写的Demo难住了，比如仓储模式，使用过它的朋友应该知道，如果你的项目不是按照DDD的架构而引入仓储的设计，那么会让它变得很“鸡肋”，用不好就会十分痛苦，之前看过这篇 博客园的大牛们，被你们害惨了，Entity Framework从来都不需要去写Repository设计模式 文章的朋友应该还记得，不止是该文章的作者，很多园友在评论里面也提到了使用它的不爽。博主的项目中也遇到类似的问题，虽然引入了仓储模式，但是由于没有架构好，把仓储的接口和实现统一放在了数据访问层，导致到后面代码越写越难维护，完全感觉不到仓储带来的好处。所以博主觉得单纯分享仓储模式很容易使读者陷入“为了模式而模式”的误区，再加上最近一段时间在看《领域驱动设计：软件核心复杂性应对之道.Eric.Eva》这本书和博客园大牛dax.net的DDD系列文章，所以打算分享一个Demo来说明仓储模式、Automapper、WCF等知识点。
DDD领域驱动设计初探系列文章：
C#进阶系列——DDD领域驱动设计初探（二）：仓储Repository（上）
C#进阶系列——DDD领域驱动设计初探（三）：仓储Repository（下）
C#进阶系列——DDD领域驱动设计初探（五）：AutoMapper使用
C#进阶系列——DDD领域驱动设计初探（七）：Web层的搭建
一、领域驱动设计基本概念根据《领域驱动设计：软件核心复杂性应对之道.Eric.Eva》书中的观点，领域模型是软件项目的公共语言的核心，是领域专家和开发人员共同遵守的通用语言规则，那么在DDD里面，建模的重要性不用多说，所以要想更好理解领域驱动设计，理解领域模型的划分和建立就变得相当必要。首先来看看DDD里面几个比较重要的概念：
1、领域模型：领域模型与数据模型不同，它表述的是领域中各个类及其之间的关系。从领域驱动设计的角度看，数据库只不过是存储实体的一个外部机制，是属于技术层面的东西。数据模型主要用于描述领域模型对象的持久化方式，应该是先有领域模型，才有数据模型，领域模型需要通过某种映射而产生相应的数据模型，从这点来说，最新的EF的Code First就是一个很好的体现。领域模型对象分为实体、值对象和服务。
2、实体：在领域驱动设计里面，实体是模型中需要区分个体的对象。这里的实体和EntityFramework里面的实体不是一个概念，EF的实体为数据实体，不包含对象的行为。就博主的理解，DDD概念里面的实体就是包括实体数据(EF的Model)和行为的结合体。
3、值对象：通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。相比实体而言，值对象仅仅是比实体少了一个标识。值对象的设计比较存在争议，我们暂且记住值对象和实体的区别：（1）实体拥有唯一标识，而值对象没有；（2）实体允许变化，而值对象不允许变化；（3）判断两个实体相等的方法是判断实体的标识相等，而判断两个值对象相等的标准是值对象内部所有属性值相等；
4、聚合（以及聚合根）：聚合表示一组领域对象(包括实体和值对象)，用来表述一个完整的领域概念。而每个聚合都有一个根实体，这个根实体又叫做聚合根。举个简单的例子，一个电脑包含硬盘、CPU、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合根。博主觉得关于聚合的划分学问还是挺大的，需要在实践中慢慢积累。同一个实体，在不同的聚合中，它可能是聚合根，也可能不是，需要根据实际的业务决定。聚合根是聚合所表述的领域概念的主体，外部对象需要访问聚合内的实体时，只能通过聚合根进行访问，而不能直接访问。