gameboyLV
2013-01-18 09:31

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

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

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

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

clonalman
2013-01-18 12:26

2013-01-16 20:25 "@gameboyLV"的内容
直到前段时间我才发现,构建在数据层之上的领域层完全就是一个错误,领域层应当处于整个项目中的最底层,而且完全不用继承IEntity,IRepository之类的接口,正是这些接口绑架了领域模型。 ...

恭喜恭喜啊,这种机会不多的。

别忘了把架构信息也踢处领域,那就彻底解放了。

领域不一定是最低层,但其它各层都是围绕着它转的

flyzb
2013-01-19 09:36

2013-01-18 12:26 "@clonalman"的内容
直到前段时间我才发现,构建在数据层之上的领域层完全就是一个错误,领域层应当处于整个项目中的最底层,而且完全不用继承IEntity,IRepository之类的接口,正是这些接口绑架了领域模型 ...

    我完全反对这样的做法。因为领域模型主要是一个逻辑模型的体现,而仓储层本质上是帮助领域模型屏蔽了数据库。

  如果你认为这样做才是真正解放了领域模型,那么请问当数据库从关系型变成nosql时,你的领域模型是否还能保持不变?

gameboyLV
2013-01-19 11:28

当然可以,在我的值对象和数据实体之间有一层数据转换服务(防腐层),当数据实体变成bson,datatable,或二进制文件时,只需要在防腐层中添加对应的转换器即可,领域模型可保持不变。

甚至可以一套领域模型同时使用NOSQL和SQL两种存储机制,当防腐层检测到SQL持久化服务当机时自动切换到NOSQL的持久化服务。

flyzb
2013-01-19 14:36

从图上看,个人总体感觉"文不对题",有些混乱。

既然是“仓储”,那就是与数据库打交道的,这个定义是很清晰的,但"仓储“在本图中的位置竟然在领域对象之上,完全不符合DDD的定义。

既然是”领域服务“,那就是领域层对外的被调用接口,也就是领域的逻辑外观,但'领域服务"在本图中是被“仓储”调用而与领域对象无关。

6Go 上一页 1 2 3 4 5 ... 6 下一页