先说说之前几次DDD项目失败的案例，其实也不能算是失败，只是没有领会DDD的思想。

之前的DDD是建立在数据层之上的，首先是每张数据表对应一个数据实体，每个数据实体由泛型的DAO管理，DAO又被数据上下文继承以实现事务，这就构成了数据层，业务代码是写在DataContext中。

数据层：DataEntity <- DataMapper<DataEntity> <- DataContext

在这样的数据层之上构建了“貌似”DDD的领域层，首先由领域对象继承数据上下文以实现序列化和脏读校验等功能，聚合根又继承领域对象以实现级联更新、延迟加载和管理领域对象之间的关联，最后由实现了LINQ查询的仓储对象管理聚合根，这就是当时的领域层。

领域层：DataContext <- Entity <-RootEntity <- Repository

这套架构陆陆续续用了1年左右，在运用的过程中发现DDD除了增加项目的复杂程度之外，没有带来任何好处，这是为什么呢？

直到前段时间我才发现，构建在数据层之上的领域层完全就是一个错误，领域层应当处于整个项目中的最底层，而且完全不用继承IEntity，IRepository之类的接口，正是这些接口绑架了领域模型。

==================分割线==================

经过重新设计的领域层今天终于完工了，处于最底层的仍旧是数据实体，原来的泛型DAO和DataContext全部都移动到了横切层，以类似于切面的方式向领域层提供服务。

数据实体之上是值对象，值对象是完全按照领域需求构建的。数据实体和值对象之间还有一层薄薄的数据转换服务，用于将面向数据库的数据实体转换为面向领域的值对象。
　　　　　　　　　　　　　　　　　　　　
数据层：DataEntity <-> Data Transformation Services <-> ValueObject

数据层之上是领域层，一个领域对象内持有若干个值对象，领域对象负载维护自生的状态，和领域对象处于同一层次的是领域服务，领域服务更倾向与处理业务逻辑，在两者之上有仓储对象，仅负责查询。

领域层：Entity / Service <- Repository

构建在数据层和领域层之外的是横切层，横切层提供轻量级的数据服务，例如事务管理、对象缓存，单例模式的DataMapper。这些服务都是以using的方式提供，即：只能在小范围的函数块内使用，使用过后自动销毁。

横切层：EventManager / CacheManager / DataManager 等。

==================分割线==================

现在的领域层已经处于整个项目的最底层了，ValueObject完全是按照领域的对象的需求构建的，使用起来得心应手。

今天在一个大项目中实践后发现，完全可以不参考UI设计，不参考原型设计，只按照需求说明书设计领域结构，设计完成之后的领域模型居然很神奇的符合UI和原型的需求。

这样的开发流程似乎也很符合TDD的理念，接口先行、之后是测试、再后来是功能、最后才是UI。

原来的数据层现在分散到了3个部分：
1、删除重量级的ORM功能，例如级联更新，延迟加载、连表查询等
2、基本的单表持久化移动到横切层，注意最下面一条虚线，现在数据持久化是通过数据实体发消息给数据存储实现的。
3、缓存管理、事务管理移动到横切层，现在直接缓存领域对象，而不是缓存数据实体

也就是说，现在已经没有传统意义上的数据层了，数据存储都是通过消息机制将更改DataEntity的操作传递到持久化服务，持久化服务只有非常简单的CUD功能，可以连接到Sql,NoSql甚至XML文件。

这正是这张图想表达的内容，仓储层并不需要和数据库进行交互。

我们习惯性的思维，仓储需要接受一个请求，然后查询数据库获得数据实体，再将数据实体转换为领域对象。人总是有惰性的，有时候为了省事，数据实体就直接参与业务逻辑、甚至是返回给UI了。

在这张图上，领域层、应用层、UI层都是访问不到数据实体的，对领域对象进行的任意操作都会经由数据转换服务（防腐层）转换为若干条DataEntity.Change消息，数据存储（持久化服务）复杂侦听这些消息，并连接数据库。

也就是说领域层只需要修改数据，而不需要关心持久化的问题。

http://www.jdon.com/44900