5

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

但是尝试遵循 DDD 我质疑这些属性是否真的是域的一部分并且应该包含在域对象中。如果我要从域中排除这些“元数据”属性，但仍希望它们在我的数据库中，那么如果我要使用 ORM，我需要实现某种 DTO 层。

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

所以我想我的问题是：

  1. 我是否只是将这些属性作为我的域模型的一部分？
  2. 我是否删除了它们，但不得不映射 DTO 感到头疼？
  3. 是否有替代方案可以消除这两个问题，例如实施某种形式的审计日志？
4

3 回答 3

6

在进行领域驱动设计时，您的实体通常与数据库的结构没有太大关系。

您很快就会发现，无论如何，您都需要在 ORM 的表对象和您的域的聚合之间进行映射。

将数据库驱动的方面强加到您的域模型中与 DDD 的全部内容相矛盾。

所以是的，我建议将 ORM 的表对象（无论如何都是纯数据）映射到您的聚合中。这就是存储库模式发挥作用的地方。它将通过转换底层数据来提供域的对象。

如果像创建/修改日期和用户这样的元数据本质上不是业务域的一部分（即系统范围的日志记录要求），则可以在转换回表对象以保存时注入给定的用户和日期/时间。

分层架构可能如下所示：

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

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

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

 ----------------------------
| Database                   | (this is where the data lives)
 ----------------------------
于 2013-05-28T15:33:54.040 回答
3

找出这一点的唯一方法是询问您的产品负责人这些字段是否与您的模型相关。如果是，它们与哪些实体相关？

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

为什么？它们不是模型的一部分，这意味着它们不是您领域中任何逻辑的一部分。

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

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

于 2013-05-28T15:28:49.890 回答
1

我同意其他答案，即“元数据”不一定是域的一部分。

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

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

于 2013-05-29T04:23:10.293 回答