在 DDD 中，实体的集合属性是否允许具有部分值？
在领域驱动设计中，实体的集合属性是否允许具有部分值？
例如，诸如 Customer.Orders、Post.Comments、Graph.Vertices 之类的属性是否应该始终包含所有订单、评论、顶点，还是允许包含今天的订单、最近的评论、孤立的顶点？
相应地，存储库是否应该提供
GetCustomerWithOrdersBySpecification
GetPostWithCommentsBefore
诸如此类的方法？
In Domain Driven Design are collection properties of entities allowed to have partial values?
For example, should properties such as Customer.Orders, Post.Comments, Graph.Vertices always contain all orders, comments, vertices or it is allowed to have today's orders, recent comments, orphaned vertices?
Correspondingly, should Repositories provide methods like
GetCustomerWithOrdersBySpecification
GetPostWithCommentsBefore
etc.?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请记住，领域驱动设计还有一个服务的概念。 对于执行某些数据库查询，最好将问题建模为服务，而不是建模为附加到父对象的子对象的集合。
一个很好的例子是通过接受多个用户输入的参数来创建报告。 容易
将其建模为：比这样更
：或者换句话说，用于数据输入的 DDD 模型不必与用于报告的 DDD 模型相同。
在高度可扩展的系统中，通常将这两个问题分开。
Remember that Domain-Driven Design also has a concept of services. For performing certain database queries, it's better to model the problem as a service than as a collection of child objects attached to a parent object.
A good example of this might be creating a report by accepting several user-entered parameters. It be easier to model this as:
Than like this:
Or to put it another way, the DDD model you use for data entry does not have to be the same as the DDD model you use for reporting.
In highly scalable systems, it's common to separate these two concerns.
我不认为 DDD 告诉你要不要这样做。 这在很大程度上取决于您正在构建的系统以及您需要解决的具体问题。
我什至没有听说过这方面的模式。
从主观的角度来看，我想说实体应该通过定义来完成（考虑延迟加载），并且可以完全或部分加载到 DTO，以优化发送到客户端的数据量。 但如果可以解决某些问题，我不介意从数据库加载部分实体。
I don't think that DDD tells you to do or not to do this. It strongly depends on the system you are building and the specific problems you need to solve.
I not even heard about patterns about this.
From a subjective point of view I would say that entities should be complete by definitions (considering lazy loading), and could completely or partially be loaded to DTO's, to optimized the amount of data sent to clients. But I wouldn't mind to load partial entities from the database if it would solve some problem.