Architecture 域模型上的表示属性？

在DDD和域建模的上下文中，假设我有一个

Product

类，它具有

id

，

price

属性，我在业务逻辑中广泛使用这些属性。但是，我的表示层还需要

图像

属性。我不认为我应该把它放在我的领域层中（因为我的业务逻辑没有用到它），但是我正在努力思考应该把它放在哪里。我是否应该创建一个

ProductViewModel

并从

Product

类的某个地方组装它？组装应该在应用层完成吗？这里有哪些选项？

：

使用DTO之类的工具非常有用的一种情况是，表示层中的模型与底层域模型之间存在严重的不匹配。在这种情况下，创建特定于表示的facade/gateway是有意义的，它从域模型映射，并提供一个便于表示的接口。它非常适合表示模型。我希望在新的一卷中更多地讨论这个问题。这是值得做的，但它只值得为有这种不匹配的屏幕做（在这种情况下，这不是额外的工作，因为您无论如何都必须在屏幕上做。）

因此，似乎可以创建某种

ProductViewModel

关于应该创建模型的位置，他说正确的方法是创建某种

ProductViewModelAssembler

，它知道如何加载、保存和更新模型

---

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

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

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

查询也被发送到我的服务层，但是应用层绕过域层直接查询数据库；因此，它不使用域实体，但有自己的查询实体（表示实体，如果您愿意）；与域实体不同

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

---

您没有给出关于体系结构外观的详细信息（您向表示层公开了哪些实体？域实体本身，或DTO的？外观），而且您似乎没有这种分离，但同样的概念仍然适用：如果图像是表示问题，不要将其添加到域实体中。一个有效的选项可能是创建一个包含image属性的视图模型，您的控制器将负责正确构造它。

为什么不在实体上放置一个名为image的属性？如果您在业务概念上的产品有一个“映像”，我看不出有什么问题为什么不在您的实体中包含此属性。即使此属性没有行为，它也是您的域实体的一部分。正如我在问题中所说-

Image

不属于任何业务层。映像是否属于不同的有界上下文？是否有领域专家关心图像（即关心维护目录的人）？可能我不清楚什么是有界上下文-如果提到的

产品
在目录上下文中（因此，演示文稿使用
图像
属性，即使任何聚合都不对其执行任何业务逻辑）我仍然应该将其放在
产品
上？