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

发布时间：2020-12-14 04:58:35 所属栏目：百科来源：网络整理

导读：当按标准为数据库中的每个表编写应用程序时,我具有以下属性：CreatedOn,CreatedBy,ModifiedOn,ModifiedBy,Archived. 但是试图跟踪DDD我在质疑这些属性是否真的是域的一部分,应该包含在域对象中.如果我要从域中排除这些“元数据”属性但仍然希望它们在我的数

当按标准为数据库中的每个表编写应用程序时,我具有以下属性：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)
 ----------------------------

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!