Database DDD、数据库和数据清单

我正在开始我的第一个真正的软件项目，我想马上开始。DDD的概念似乎是一种非常干净的方法，它将不同的软件部分分开，但是在现实中我很难实现这一点

我的软件是测量跟踪器，基本上存储测量数据列表，包括时间戳和数据值

我的域模型

class MeasurementDM{
   string Name{get;set;}
   List<MeasurementPointDM> MeasurementPoints{get;set;}
}

class MeasurementPointDM{
   DateTime Time{get;set;}
   double Value{get;set;}
}

我现在有以下问题：

1因为我想保持我的域模型的纯净，所以我不想要或不需要这些类中的数据库键。从数据库构建域模型时，这没有问题，但我不知道如何存储它们，因为域模型不再知道数据库Id。我是否应该在域模型中包含此项？当我从数据库检索域对象时，是否应该创建一个字典，将它们映射到数据库ID

2测量点本质上与测量本身具有相同的Id问题。此外，我不确定存储测量点本身的正确方法。在上面，每个MeasurementPointPM都知道它属于哪个MeasurementTPM。当我查询时，我只是根据度量键选择度量点。这是存储此类数据的有效方法吗？随着越来越多的测量数据的增加，这种情况似乎会爆发。我是否最好将度量点列表序列化为字符串，并将整个列表存储为nvarchar？这将使添加和删除数据点变得更加困难，因为Id总是需要反序列化、重新序列化整个列表

我很难找到一个处理这些问题的DDD的好例子，希望有人能帮助我

我的软件是测量跟踪器，基本上存储测量数据列表，包括时间戳和数据值

您可能需要仔细考虑您是在描述服务还是数据库。如果您的主要用例是存储来自其他地方的信息，那么在混合中引入域模型可能不会让您的生活变得更好

当新信息与旧信息交互时，域模型被测试为有趣的。因此，如果您只有数据结构，就很难找到一个好的模型，因为缺少关键元素——模型实体如何随时间变化

也就是说

我不知道如何存储它们，因为域模型不再知道数据库Id

这不是你的错。文学很烂

最常见的答案是，人们允许他们的模型受到O/RM问题的污染。例如，如果您查看Citerus示例应用程序中的实体，您会发现下面隐藏的行：

Cargo() {
    // Needed by Hibernate
}

// Auto-generated surrogate key
private Long id;

这是一个间接的结果，因为存储库模式提供了一个保持其自身状态的内存中对象集合的假象，而实际情况是您正在内存和持久存储之间复制值

也就是说，如果您想要一个干净的域模型，那么您需要为存储的数据提供一个单独的内存表示，以及在这两者之间来回转换的函数

换句话说，您遇到的是违反单一责任原则的情况——如果您使用与管理持久性相同的类型对域进行建模，那么结果将是这两个问题的混合

---

所以本质上你会说域模型的一些最小污染，例如Id，是标准的实践

不太强壮；我想说这是一种普遍的做法。从根本上说，很多人，特别是在项目的早期阶段，不重视在他们的域模型和持久性管道之间有一个平衡点

让每个域模型从基类继承或者实现一个强制创建唯一Id的接口有意义吗

可以。在web上有很多示例，其中域实体扩展了一些通用实体或聚合模式

真正有趣的问题是

这样做的直接成本和收益是什么？ 这样做的递延成本和收益是什么？

---

特别是，这会使事情更容易改变还是更难改变？

因此，从本质上说，域模型的一些最小污染，例如Id，是标准做法。所以我会有一个MeasurementDM域模型，它有一个Id，可以转换成MeasurementTPM持久性模型，它本身可以很容易地存储在数据库中。让每个域模型从基类继承或者实现一个强制创建唯一Id的接口有意义吗？@ClaudeHasler您是否考虑过客户端生成的密钥，例如GUID/UUID？这将使您不必担心持久层中的键 而是谈论聚合的身份。

Cargo() {
    // Needed by Hibernate
}

// Auto-generated surrogate key
private Long id;