摘抄来自论坛的一些DDD讨论
先说说之前几次DDD项目失败的案例，其实也不能算是失败，只是没有领会DDD的思想。之前的DDD是建立在数据层之上的，首先是每张数据表对应一个数据实体，每个数据实体由泛型的DAO管理，DAO又被数据上下文继承以实现事务，这就构成了数据层，业务代码是写在DataContext中。数据层：DataEntity <- DataMapper <- DataContext在这样的数据层之上构建了“貌似”DDD的领域层，首先由领域对象继承数据上下文以实现序列化和脏读校验等功能，聚合根又继承领域对象以实现级联更新、延迟加载和管理领域对象之间的关联，最后由实现了LINQ查询的仓储对象管理聚合根，这就是当时的领域层。领域层：DataContext <- Entity <-RootEntity <- Repository这套架构陆陆续续用了1年左右，在运用的过程中发现DDD除了增加项目的复杂程度之外，没有带来任何好处，这是为什么呢？直到前段时间我才发现，构建在数据层
原来的数据层现在分散到了3个部分：
1、删除重量级的ORM功能，例如级联更新，延迟加载、连表查询等
2、基本的单表持久化移动到横切层，注意最下面一条虚线，现在数据持久化是通过数据实体发消息给数据存储实现的。
3、缓存管理、事务管理移动到横切层，现在直接也就是说，现在已经没有传统意义上的数据层了，数据存储都是通过消息机制将更改DataEntity的操作传递到持久化服务，持久化服务只有非常简单的CUD功能，可以连接到Sql,NoSql甚至XML文件。
这正是这张图想表达的内容，仓储层并不需要和数据库进行交互。
我们习惯性的思维，仓储需要接受一个请求，然后查询数据库获得数据实体，再将数据实体转换为领域对象。人总是有惰性的，有时候为了省事，数据实体就直接参与业务逻辑、甚至是返回给UI了。
在这张图上，领域层、应用层、UI层都是访问不到数据实体的，对领域对象进行的任意操作都会经由数据转换服务（防腐层）转换为若干条DataEntity.Change消息，数据存储（持久化服务）复杂侦听这些消息，并连接数据库。
也就是说领域层只需要修改数据，而不需要关心持久化的问题。
http://www.jdon.com/44900