我有2个业务实体（对象）：产品和订单。除了一些其他属性之外，Product对象还包含“Name”属性。订单实体除了指向产品的属性外还包含“Id，Date ...等”属性（假设订单为了简单起见只能有一个产品）
在我的情况下，当我想显示订单列表时，我想显示每个订单的产品名称，但我不需要显示其他产品的属性。
我的问题是，当我设计Order实体类时，我应该添加一个指向Product的属性，还是应该添加一个名为“ProductName”的属性？如果答案是添加一个指向Product的属性，是否可以只加载Name属性，或者我也应该填充所有其他属性（在从DB检索数据时）？
如果你能用你的答案添加一些文章的链接，我也将不胜感激。
答案 0 :(得分：1)
这只是CQRS的问题。要显示与UI相关的任何内容，只需让查询处理程序（服务）直接从db（持久性）获取所需的视图模型数据，因此将跳过Business / Domain层。这就是全部。 您不应该根据用户界面需求设计商业模式。
在处理更改业务模型的状态（命令部分CQRS）时，设计应反映概念及其关系。在您的情况下，订单引用一个或多个产品使用其ID。此模型不应用于查询，仅用于创建/更新。
要查询内容，根据您的持久性实现，您可以使用现有的db数据或在域状态更改时自动创建的用例相关读取模型（通过域事件处理程序）（但这是一个更复杂的情况，它取决于在适当的域事件设计，基于消息的架构和无法轻易查询的存储上。
答案 1 :(得分：0)
在您的问题中似乎有一个假设，即订单显示内容必须与订单实体1-1匹配。
我认为你为自己挖了一个漏洞，试图将每个订单简化为一个产品。
如果你有一个连接表（OrderProducts？或者更好的是OrderLines。订单和产品实体都不必彼此“了解”。 您可以保持这些简洁，并将此DisplayOrders函数委托给新的Join实体。
也许如果我假装是客户并说我希望订单显示不再显示ProductName，而是显示总订单价值。
这将是你的实体的很多重新调整，如果你保持这个1-1匹配的想法，你的数据库也是如此。
不要去那里。改变是给定的。 IP 评论后......
如果它确实是1 - 1关系，那么您不需要两个实体。 1-1将是每个订单一个产品，每个产品一个订单。
我愚蠢地假设你的问题实际上你可以订购多次产品。
因此，大多数有趣的方法（除了两个实体的基本粗略）都基于两个实体之间的关系。这是你应该建模的领域的一部分。
经过更多评论......
除非我对性能进行优化，否则我永远不会非规范化，如果我没有更好的选择，我就会“最后”。
如果您在谈论从依赖对象中需要一个属性，我会动态创建实体，并将publisherid放在图书实体上。
我假设发布商实体的名称属性可能会发生变化。反规范意味着我必须捕获对出版商名称的更改，阅读所有书籍并更改其名称。更糟糕的是，那里有一个隐藏的假设，即出版商名称是唯一的。现在你可以继续使用它，但是为了避免一个真正可怕的错误，如果用户的一些鼻屎给两个发布者同名，你就必须强制执行它。
在这个故意限制的示例之外的现实世界中，我希望将伪实体BookListItem分配给某些功能（例如选择它作为阅读列表或购物车），我会被一个非常诱惑第三个第一类实体BookListItem，也许是第四个BookList。
所有的设计都是妥协，如果你要看很多书的清单，出版商的名字将是一个蓝月亮的操作，你准备好身份问题，你可以预见没有改变这种行为，然后非规范化是一个很好的妥协。
在某些方面，您的问题没有正确的答案，您需要明确的是您的设计允许/启用的内容以及它所施加的限制，例如： PublisherName是唯一的，在要求中没有任何地方，可能会导致您的客户给您打电话给各种名字......
HTHS