域模型上的表示属性？答案

【问题标题】：Presentation properties on domain models?域模型上的表示属性？
【发布时间】：2014-07-03 18:14:39
【问题描述】：

在 DDD 和域建模的上下文中，假设我有一个 Product 类，它具有我在业务逻辑中广泛使用的 id、price 属性。但是，我的表示层还需要一个 image 属性。我认为我不应该把它放在我的领域层中（因为我的业务逻辑没有使用它），但是我试图考虑把它放在哪里合适。我应该创建一个ProductViewModel 并从某个地方的Product 类组装它吗？组装应该在应用层完成吗？这里有哪些选项？

【问题讨论】：

为什么不在您的实体上放置一个名为 Image 的属性？如果您在业务概念上的产品具有“图像”，我认为没有问题为什么不在您的实体中包含此属性。即使此属性没有行为，它也是您域实体的一部分。
正如我在问题中所说的 - image 不属于任何业务层。
图像是否属于不同的有界上下文？是否有关心图像的领域专家（即关心维护目录的人）？
也许我不清楚什么是有界上下文 - 如果提到的 Product 在目录上下文中（因此演示文稿使用 image 属性，即使 any 的聚合不对其执行任何业务逻辑）我仍然应该把它放在Product 上？

标签： architecture domain-driven-design modeling

【解决方案1】：

Referring to Martin Fowler:

使用 DTO 之类的东西很有用的一种情况是，当您的表示层中的模型与底层域模型之间存在严重不匹配时。在这种情况下，使表示特定的外观/网关从域模型映射并呈现便于表示的界面是有意义的。它非常适合演示模型。我希望在新卷中更多地讨论这个问题。这是值得做的，但只对有这种不匹配的屏幕才值得做（在这种情况下，它不是额外的工作，因为无论如何你都必须在屏幕上做。）

所以创建某种ProductViewModel 似乎没问题。

关于应该创建它的位置Martin Fowler 说正确的方法是创建某种知道如何加载、保存和更新模型的ProductViewModelAssembler。

在我的上一个项目中，我们设法不使用汇编程序，而只是在 DTO 中创建了构造函数，以接受所有需要创建的数据。但是你仍然需要编写一些代码来保存和更新底层领域模型。

【讨论】：

【解决方案2】：

通常我总是将查询与命令分开。

命令从消费者（例如客户端应用程序）发送到我的服务层。然后服务层将请求路由到应用层，在应用层中域和基础设施层用于执行请求。

查询也发送到我的服务层，但随后应用层绕过领域层，直接查询数据库；所以它不使用域实体，但它有自己的查询实体（如果你喜欢，表示实体）；与域实体不同。

如果我将您的情况投射到此架构中，那么它将是负责构建查询结果实体（包括图像）的应用层。由于域层不用于查询，域实体不知道图像。

您没有提供有关您的架构的详细信息（您向表示层公开了哪些实体？域实体本身，还是 DTO？看here），而且您似乎没有这种分离，但同样的概念仍然适用：如果图像是一个展示问题，请不要将它添加到您的域实体中。一个有效的选择可能是创建一个包含图像属性的视图模型，并且您的控制器将负责正确地构造它。

【讨论】：