域对象包含大量数据

Question

我们的域需要处理大量（可能超过1000个记录）对象作为域概念。这主要是Domain业务逻辑需要使用的历史数据。通常这种处理依赖于存储过程或其他一些服务来完成这种工作，但由于它与所有密切相关，我们希望保持模型的有效性，我们希望找到一个解决方案，允许Aggregate管理处理数据所需的所有业务逻辑和规则。

基本上，我们谈论的是过去的交易数据。我们的想法是构建一个轻量级类，并为我们需要从数据库中处理的每个事务创建一个实例。我们对此感到不舒服，因为我们要实例化的对象数量和潜在的性能损失，但我们同样不喜欢将这个Domain逻辑卸载到存储过程，因为这会破坏我们模型的一致性。

关于我们如何处理这个问题的任何想法？

Answer 1

对于简单的物体，“1000”并不是那么大的数字。我知道我工作的系统中的给定线程可能在给定时间持有成千上万个域对象，而其他线程同时执行相同操作。当你考虑到一个相当复杂的应用程序中发生的所有不同事情时，1000个对象就像是一滴水。

YMMV取决于这些对象所持有的资源类型，系统负载，硬性能要求或任何其他因素，但如果，如你所说，它们只是“轻量级”对象，我会在你尝试过于花哨之前，确保你的手上确实存在性能问题。

Answer 2

Lazy loading 是一种缓解此问题的技术，大多数流行的对象关系管理解决方案都实现了这一功能。它有批评者（例如，见this answer to Lazy loading - what’s the best approach?），但其他人认为延迟加载是不可或缺的。

<强>赞成

• 可以将聚合的内存占用减少到可管理的水平。
• 让您的ORM基础架构为您管理units of work。
• 如果您不需要大量子数据，则可能比完全实现（“保湿”）您的聚合根更快。

<强>缺点

• Chattier一次性实现您的聚合。你做了很多小数据库的旅行。
• 通常需要对域实体类进行体系结构更改，这可能会损害您自己的设计。 （例如，NHibernate只需要你公开一个默认构造函数，让你的实体虚拟化以利用延迟加载 - 但我已经看到其他更具侵入性的解决方案。）

相比之下，另一种方法是创建多个类来表示每个实体。这些类基本上是针对特定用例量身定制的部分聚合。这样做的主要缺点是，您冒着夸大类客户数和域客户需要处理的逻辑数量的风险。

Answer 3

当你说1000条记录值时，你的意思是1000个表还是1000行？将多少数据加载到内存中？

Answer 4

这完全取决于对象的内存占用量。如果有问题的对象引用了过程中不感兴趣的其他对象，则延迟加载确实会有所帮助。

如果您最终遇到性能问题，您必须问问自己（或者您的客户）是否必须同步运行该进程，或者是否可以将其卸载到其他地方的批处理进程。

Using DDD, How Does One Implement Batch Processing?