包含大量数据的域对象
我们的领域需要将大量（可能超过 1000 条记录）对象作为领域概念进行处理。这主要是领域业务逻辑需要使用的历史数据。通常这种处理依赖于存储过程或其他一些服务来完成这种工作，但由于它都是与域密切相关的，并且我们希望保持模型的有效性，因此我们希望找到一个解决方案允许聚合管理处理数据所需的所有业务逻辑和规则。
本质上，我们谈论的是过去的交易数据。我们的想法是构建一个轻量级类，并为我们需要从数据库处理的每个事务创建一个实例。我们对此感到不舒服，因为我们要实例化的对象量很大并且可能会影响性能，但我们同样对将此域逻辑卸载到存储过程感到不舒服，因为这会破坏模型的一致性。
关于我们如何解决这个问题有什么想法吗？
Our Domain has a need to deal with large amounts (possibly more than 1000 records worth) of objects as domain concepts. This is largely historical data that Domain business logic needs do use. Normally this kind of processing depends on a Stored Procedure or some other service to do this kind of work, but since it is all intimately Domain Related, and we want to maintain the validity of the Model, we'd like to find a solution that allows the Aggregate to manage all of the business logic and rules required to work with the data.
Essentially, we're talking about past transaction data. Our idea was to build a lightweight class and create an instance for each transaction we need to work with from the database. We're uncomfortable with this because of the volume of objects we'd be instantiating and the potential performance hit, but we're equally uncomfortable with offloading this Domain logic to a stored procedure since that would break the consistency of our Model.
Any ideas on how we can approach this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对于简单的对象来说，“1000”并不是一个很大的数字。我知道我工作的系统中的给定线程可能在给定时间持有数以万计的域对象，而其他线程同时也在做同样的事情。当您考虑一个相当复杂的应用程序中发生的所有不同事情时，1000 个对象只是杯水车薪。
YMMV 取决于这些对象所持有的资源类型、系统负载、硬性能要求或任何其他因素，但如果正如您所说，它们只是“轻量级”对象，我会确保您在你尝试变得太花哨之前，你实际上已经遇到了性能问题。
"1000" isn't really that big a number when it comes to simple objects. I know that a given thread in the system I work on may be holding on to tens of thousands of domain objects at a given time, all while other threads are doing the same at the same time. By the time you consider all of the different things going on in a reasonably complicated application, 1000 objects is kind of a drop in the bucket.
YMMV depending on what sort of resources those objects are holding on to, system load, hard performance requirements, or any number of other factors, but if, as you say, they're just "lightweight" objects, I'd make sure you actually have a performance problem on your hands before you try getting too fancy.
延迟加载是缓解此问题的一种技术，并且大多数流行的对象关系管理解决方案实现了它。它有批评者（例如，请参阅这个延迟加载的答案 - 什么是最好的方法？），但其他人认为延迟加载必不可少。
优点
缺点
相比之下，另一种方法是创建多个类来表示每个实体。这些类本质上是针对特定用例定制的部分聚合。这样做的主要缺点是，您可能会冒增加域客户端需要处理的类数量和逻辑量的风险。
Lazy loading is one technique for mitigating this problem and most of the popular object-relational management solutions implement it. It has detractors (for example, see this answer to Lazy loading - what’s the best approach?), but others consider lazy loading indispensable.
Pros
Cons
By contrast, another approach would be to create multiple classes to represent each entity. These classes would essentially be partial aggregates tailored to specific use cases. The main drawback to this is that you risk inflating the number of classes and the amount of logic that your domain clients need to deal with.
当您说 1000 条记录值得时，您是指 1000 个表还是 1000 行？有多少数据会被加载到内存中？
When you say 1000 records worth, do you mean 1000 tables or 1000 rows? How much data would be loaded into memory?
这一切都取决于对象的内存占用。如果相关对象引用了您的进程中不感兴趣的其他对象，则延迟加载确实会有所帮助。
如果您最终遇到性能问题，您必须问自己（或者可能是您的客户）该进程是否必须同步运行，或者是否可以将其卸载到其他地方的批处理进程。
如何使用 DDD 实现批处理？
It all depends on the memory footprint of your objects. Lazy loading can indeed help, if the objects in question references other objects which are not of interest in your process.
If you end up with a performance hog, you must ask yourself (or perhaps your client) if the process must run synchronously, or if it can be offloaded to a batch process somewhere else.
Using DDD, How Does One Implement Batch Processing?