DDD - 域模型中的CreatedBy / CreatedOn？

Question

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

但是尝试跟踪DDD我质疑这些属性是否真正属于域，应该包含在域对象中。如果我要排除这些＆＃34;元数据＆＃34;来自域的属性但仍然希望它们存在于我的数据库中，那么如果我打算使用ORM，我需要实现某种DTO层。

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

所以我想我的问题是：

1. 我是否只将这些属性作为我的域模型的一部分？
2. 我是否删除它们但是必须要映射DTO＆＃39;
3. 是否有替代方案可以消除诸如实施某种形式的审核日志这两个问题？

Answer 1

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

您很快就会到达某个角落，无论如何您需要在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)
 ----------------------------

Answer 2

找到答案的唯一方法是询问您的产品所有者这些字段是否与您的模型相关。如果它们是，它们与哪些enteties相关？

---

  

如果我要从域中排除这些“元数据”属性但仍想在我的数据库中使用它们那么我会[.....]

为什么呢？它们不是模型的一部分，因为它们不属于您域中的任何逻辑。

  

3.是否存在可以消除诸如实施某种形式的审计日志这两个问题的替代方案？

如果需要审核日志，那么它们应该是模型的一部分。

Answer 3

我同意其他答案，指出'元数据'不是必然域的一部分。

如果您的域是身份和访问控制域，那么您将涉及用户名等。对于使用Identity和Access BC的任何事情，事情可能会有所不同。您可能需要以值对象的形式将一些用户信息添加到域中。

在大多数情况下，我觉得这些数据属于应用程序服务级别。可以选择让您的存储库可以访问的应用程序服务填充一些上下文对象，以便填充相关的DB字段。这样它就不会出现你的模型。