微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

设计模式 – DDD – 域模型中的CreatedBy / CreatedOn?

当按标准为数据库中的每个表编写应用程序时,我具有以下属性:CreatedOn,CreatedBy,ModifiedOn,ModifiedBy,Archived.

但是试图跟踪DDD我在质疑这些属性是否真的是域的一部分,应该包含在域对象中.如果我要从域中排除这些“元数据”属性但仍然希望它们在我的数据库中,那么如果我打算使用ORM,我需要实现某种DTO层.

因此,域模型映射到DTO,设置CreatedOn,ModifiedOn等,然后将其推送到数据库.

所以我想我的问题是:

>我是否只将这些属性作为我的域模型的一部分?
>我是否删除它们但是不得不映射DTO的头痛?
>是否有一种替代方案可以消除诸如实施某种形式的审计日志这两个问题?

解决方法

在进行域驱动设计时,您的实体通常与数据库的结构无关.

您很快就会到达某个角度,无论如何您需要在ORM的表对象和域的聚合之间进行映射.

数据库驱动的方面强制进入您的域模型与DDD的全部内容相矛盾.

所以是的,我建议将ORM的表对象(无论如何都是纯数据)映射到聚合中.这就是Repository模式发挥作用的地方.它将通过转换基础数据来提供域的对象.

如果诸如创建/修改日期和用户之类的元数据本身不是业务域的一部分(即系统范围的日志记录要求),则可以在转换回表对象以进行保存时注入给定用户和日期/时间.

分层体系结构可能如下所示:

----------------------------
| Domain                     | (Aggregates)
 ----------------------------

 ----------------------------
| Repositories               | (transforms table-objects into Aggregates)
 ----------------------------

 ----------------------------
| OR-Mapper                  | (loads records from DB into table-objects)
 ----------------------------

 ----------------------------
| Database                   | (this is where the data lives)
 ----------------------------

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐