DDD 值对象：如何在没有大量 SQL 连接的情况下持久化实体对象？答案

【问题标题】：DDD Value Object: How to persist entity objects without tons of SQL joins?DDD 值对象：如何在没有大量 SQL 连接的情况下持久化实体对象？
【发布时间】：2011-01-16 18:46:26
【问题描述】：

显然我说 DDD 在实用性上类似于 EAV/CR 是错误的，但到目前为止我看到的唯一区别是为每个实体构建的物理表具有大量连接，而不是三个表和大量连接。

这一定是由于我对 DDD 缺乏了解。 在导入数据时如何将这些对象物理存储到数据库中而不需要大量的连接和复杂性？我知道您可以简单地创建输入到您的存储库的对象，但是很难训练像 Microsoft Sql Server 这样的工具Integration Server 使用您的自定义 C# 对象和框架。也许这应该是我的问题，您如何将您的 DDD ASP.NET C# 框架与 Microsoft SQL Server 集成服务和报表服务一起使用？哈哈。

在 EAV/CR 数据库中，我们可以根据人员的类型设置具有不同类的单个人员表：供应商、客户、买方、代表、公司、清洁工等。三个表，一些连接，属性是在我们插入之前总是带有验证的字符串，就像 MVC 中的 ModelValidation 一样，对象接受任何值但在它有效之前不会持续存在。

在标准关系模型中，我们曾经为每种类型的实体创建一个表，混合了冗余数据类型，如城市。

使用领域驱动设计，我们使用对象来表示每种类型的实体，为每种类型的 ValueObject 使用嵌套对象，并根据需要使用更多嵌套对象。在我的理解中，这会为每种实体生成一个表，为每种信息集（值对象）生成一个表。对于所有这些表，我看到了很多连接。我们最终还为每种新的联系人类型创建了一个物理表。显然有更好的方法，所以我在将对象持久保存到数据库的方式上一定是不正确的。

我的供应商如下所示：

public class Vendor {
    public int vendorID {get; set;}
    public Address vAddress {get; set;}
    public Representative vRep {get;set;}
    public Buyer vBuyer {get; set;}
}

我的买家：

public class Buyer {
   public int buyerID {get; set;}
   public Address bAddress {get; set;}
   public Email bEmail {get; set;}
   public Phone bPhone {get; set;}
   public Phone bFax (get; set;}
}

我们真的引用了 Vendor.vBuyer.bPhone.pAreaCode 之类的东西吗？我认为我们会引用和存储 Vendor.BuyerPhoneNumber，并构建对象几乎就像这些部分的别名：Vendor.Address1、Vendor.Address2、Vendor.BuyerPhoneNumber ... 等等。

【问题讨论】：

标签： c# sql-server ssis domain-driven-design object-persistence

【解决方案1】：

您可以将对象序列化为 xml 并将其保存到 Sql Server 中的 xml 列中。毕竟，您正在尝试表示分层数据结构，而这正是 xml 擅长的地方。

【讨论】：

【解决方案2】：

领域驱动设计的支持者通常建议让数据模型尽可能接近对象模型，但这不是铁定的规则。

如果您在对象关系映射层中创建映射以将数据转换（投影）到对象中，您仍然可以使用 a EAV/CR database design。

决定如何设计您的对象并提供对子值的访问确实是一个单独的问题，您必须根据具体情况来解决。 Vendor.BuyerPhoneNumber 还是 Vendor.vBuyer.bPhone.pAreaCode？答案总是取决于您的具体要求。

【讨论】：

【解决方案3】：

真正的答案是将您的 SQL 规范化策略与您的对象相匹配。如果您有很多重复的地址，并且需要将它们关联在一起，则将数据规范化到单独的表中，从而产生对值对象的需求。

【讨论】：

【解决方案4】：

存储域对象的最佳方式之一实际上是文档数据库。它工作得很好，因为文档的事务边界与聚合根的一致性边界完美匹配。您不必担心 JOIN 或急切/延迟加载问题。但是，如果您应用 CQRS（我在下面写过），这并不是绝对必要的。

缺点通常是查询。如果您想直接查询域对象背后的持久数据，您可能会陷入困境。然而，这是 CQRS 旨在为您解决的复杂问题，您的应用程序执行查询的部分与加载/验证/存储域对象的部分不同。

您可能有一个复杂的“命令”实现，它加载域对象，调用它们的行为（记住域对象必须有行为并封装它们的数据，否则可能会变得“贫血”），然后再保存它们，甚至可以选择发布有关所发生事件的事件。

然后您可以使用这些事件来更新其他一些“读取存储”，尽管您不必这样做。关键是你在你的应用程序中实现了一个完全不同的垂直切片，它不必为复杂的对象模型/ORM业务而烦恼，而是直接进入数据，准确加载它需要的内容并将其返回以显示给用户。

CQRS 不困难，并且不复杂。所有它所做的只是指示您有单独的代码：

处理命令（改变状态，因此需要涉及的业务规则/不变量）。
执行查询（不会改变状态，因此不需要涉及所有复杂的业务规则/不变量，因此可以“直接”以有效的方式获取数据。

【讨论】：