Domain driven design DDD建模1:1…N与查询性能的关系

我是DDD初学者，我有一个遗留项目，它肯定会从适当的域层中受益。必须修改应用程序以支持多个应用程序和UI层。域逻辑目前是使用事务脚本模式实现的。基本上我继承了一个不允许修改的DB结构，新应用程序应该是旧应用程序的替代品

我在这个领域的一小部分偶然发现了一个有趣的建模问题，我相信有经验的DDD从业者会对此感兴趣。关于这个问题我不能说得太具体，所以我将描述一个与我的问题非常相似的问题

问题描述 让我们假设我们应该管理一系列产品。产品由ID标识，它们包含一些描述，每个产品都有一些与之相关的图像。棘手的部分来了。图像及其内容物理存储在数据库中，因此它们是巨大的数据块。（现在让我们忽略在DB中存储图像的好坏，这只是一个例子）。添加/编辑/删除产品时必须强制执行一些不变量

添加产品

• 只有当产品具有与其关联的图像时，该产品才有效，如果不添加图像，则不允许输入新产品
• 每个产品必须与5个图像关联，不多不少
• 必须维护与产品关联的图像顺序

编辑产品

• 可以替换现有产品的图像，但应保持关联图像的数量和顺序

删除产品

• 删除产品时，还应删除与之关联的所有图像

深思熟虑的解决方案

解决方案1： 对这些概念建模的最简单方法如下。 产品是AR。与产品关联的图像可以通过产品访问和修改，因此产品负责实施5图像规则。这种方法的优点是，不能以使无效产品无效的方式创建或编辑无效产品，并且在删除产品时不会留下任何图像。因此，如果在事务边界周围形成聚合。这种方法的问题在于，在绝大多数情况下，UI只需要显示产品列表，也许还需要修改它们的描述。UI很少需要显示或修改与产品关联的图像。因此，95%的情况下，大量不必要的数据会加载到内存中

延迟加载？域模型应该用一种没有支持延迟加载的ORM工具的语言来实现。实现我自己的延迟加载机制？域对象不应该知道它们被持久化的方式，或者它们是否被持久化。相反，沃恩·弗农建议使用解决方案2

解决方案2： 使用这种方法，可以通过支持小聚合和遵循身份规则引用其他聚合来解决查询性能问题。沃恩·弗农（Vaughn Vernon）对如何实现这一点有着伟大的描述

聚合分为产品和图像集两部分。它们都将ProductId作为值对象引用。产品将负责执行无产品无图像规则，图像集将执行无图像集无5图像规则。查询不再是问题，只有当服务需要时才会检索图像集。 然而，这个问题比弗农在他的文章（0…N协会）中描述的要复杂得多。问题是，创建一个产品会导致修改或创建两个聚合，从而消除了围绕事务边界建模聚合的目的。添加新产品的服务将负责事务管理

解决方案3： 最终的解决方案是使用有界上下文。为了简单起见，我们将它们命名为BC1和BC2。在BC1中，产品只包含ProductDetails。对查询产品的详细信息感兴趣的服务可能会使用BC1（BC1中的ProductRepository不允许添加或删除产品，只允许查询/修改现有产品）。在BC2中，产品将包含ProductDetails和与之关联的图像。因此，对添加/删除产品以及修改/检索其映像感兴趣的服务将使用BC2。Commmon值对象和实体将在这两个BC之间共享

此解决方案将解决所有事务一致性和查询性能问题。然而，根据他们的定义，我不确定是否应该创建BCs来应对此类问题

---

很抱歉问了这么长的问题，但我觉得我真的应该指出我已经考虑过的解决方案。对于链接的图像，很抱歉，我还不允许上传图像。

在您的用例中，一个重要的观察结果是，第一个解决方案的问题被隔离到应用程序的查询端。没有理由使用与用于查询的模型相同的模型来处理命令和强制执行约束。可以使用将读和写分开，这将允许您为特定的UI需求创建特定的读模型，并且读模型不会影响您的域模型。虽然使用与编写相同的模型进行读取很有诱惑力，特别是考虑到大多数ORM支持复杂的查询和给定的属性，但实际上，将读取模型与可执行域模型分离要容易得多

此外，沃恩·弗农（Vaughn Vernon）的系列文章是理解复杂的聚合设计的一个重要资源，但它是