我正在关注这个项目的领域驱动设计。
我有一个包含图像的对象。我们称它为Product
:
class Product {
UniqueID id;
ProductName name;
ImageBytes imageBytes;
}
UniqueID
, ProductName
和 ImageBytes
只是经过验证的对象,分别代表 String
, 一个 String
和一个 List<int>
.
我想将实际图像存储在 Firebase 存储中并保存 imageId
在 Firestore 上。
因此,在我看来,我在 Firebase 存储上有一张图像,其 ID 为 xYF87Ejid0093RTcxaWpof,并且在 Firestore 中有一个包含此 ID 而不是实际图像的文档。
我遇到的问题是编写产品的数据传输对象。我应该如何转换 imageId
进入实际图像?
请考虑我使用的是 DDD,所以我的 DTO 和我的实体类是联合(使用卡住)。
我想我应该有一个名为 FirestoreProduct
的中间类在基础架构级别看起来像这样:
class FirestoreProduct {
UniqueID id;
ProductName name;
UniqueID imageId;
}
这样我就可以编写一个使用此类的 DTO,并且我可以在下载图像后从存储库类创建 Product 对象。 DDD方式有没有更好的办法解决这个问题?
提前致谢。
最佳答案
您真的需要ImageBytes 来执行产品实体的业务逻辑吗?我什至猜测您的Product 是聚合根,因此其中包含数据和相应的行为(业务逻辑)。
所以从我的角度来看,您的 FirestoreProduct 模型比您的Product 类。
我认为您的图像是一个单独的聚合体,它可以驻留在同一服务但不同的存储空间中,或者甚至可以驻留在单独的服务中。
无论哪种方式,产品聚合 都应该只需要对图像的引用。我会以某种方式对其进行建模
class Product {
ProductId id;
ProductName name;
ImageId imageId;
而 ProductId 和 ImageId 将是强类型 ID 的值对象。
我希望新图像的存储/上传在单独的事务中执行,而不是创建/更新产品本身。这意味着当您创建新产品或对其执行某些业务逻辑以更改它时,您的图像已经上传到 Firestore,并且您只能在产品聚合中使用图像 ID。
另一方面,您用于为 UI 提供数据(即读取数据)的Product DTO(您也可以称之为 View 模型)可以看起来像与 Product 聚合不同。这没关系,也很有意义。
所以 DTO 应该看起来像这样:
class ProductDto {
UniqueID id;
ProductName name;
ImageBytes imageBytes;
}
注意:我不知道 ImageBytes 是否是 DTO 的正确类型,因为我对 flutter 的了解有限,但我希望你能理解。
有了它,您可以完全绕过产品聚合域存储库,并拥有另一个服务类,它将为您提供阅读/查看产品数据所需的所有数据。由于您不会通过读取数据更改任何内容,因此您不会遍历域模型并针对读取进行优化。
构建 DTO 的代码将转到您的持久性查询一些产品数据,但也会转到 Firebase 以查询实际图像。如果性能有问题,您甚至可以在之后通过 UI 的单独调用重新加载实际的 Firebase 图像,例如,如果您立即检索整个产品数据列表以供阅读。
关于firebase - 编写 DTO 类以构建从不同数据源获取信息的对象,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/63646417/