我正在为该项目关注域驱动设计。
我有一个包含图像的对象。我们称之为Product
:
class Product {
UniqueID id;
ProductName name;
ImageBytes imageBytes;
}
UniqueID
,ProductName
和ImageBytes
只是经过验证的对象,分别代表String
,String
和List<int>
。
我想将实际图像存储在Firebase存储上,并将imageId
保存在Firestore中。
因此,以我的想法,我在Firebase Storage上有一个ID为 xYF87Ejid0093RTcxaWpof 的图像,并且在Firestore中有一个包含此ID而不是实际图像的文档。
我遇到的问题是编写产品的数据传输对象。我应该如何将imageId
转换为实际图像?
请考虑我正在使用DDD,所以我的DTO和Entity类是联合(使用Freezed)。
我认为我应该在基础结构级别上有一个名为FirestoreProduct
的中间类,如下所示:
class FirestoreProduct {
UniqueID id;
ProductName name;
UniqueID imageId;
}
这样,我可以编写一个使用该类的DTO,并且可以在下载映像后从存储库类创建Product对象。 有什么更好的方法可以解决DDD问题吗?
谢谢。
答案 0 :(得分:2)
您真的需要 ImageBytes 来执行产品实体的业务逻辑吗?我什至猜测您的 产品 是一个聚合根,因此其中将包含数据和相应的行为(业务逻辑)。
所以从我的角度来看,您的 FirestoreProduct 的模型比您的 产品 < / em>类。
我认为您的图像是一个单独的聚合,可以驻留在同一服务中,但可以位于不同的存储中,甚至可以驻留在单独的服务中。
无论哪种方式, 产品汇总 都只需要引用图像即可。我会这样建模
class Product {
ProductId id;
ProductName name;
ImageId imageId;
}
ProductId 和 ImageId 是强类型ID的值对象。
我希望新图像的存储/上传将在单独的事务中执行,而不是创建/更新产品本身。这意味着当您创建新产品或对其执行一些业务逻辑以对其进行更改时,您的图像已被上传到Firestore,并且只能在产品集合中使用图像ID。
另一方面,用于为UI提供数据(即读取数据)的您的 产品DTO (也可以称为视图模型)与 产品 聚合不同。没关系,也很有意义。
所以DTO看起来像这样:
class ProductDto {
UniqueID id;
ProductName name;
ImageBytes imageBytes;
}
注意:我不知道 ImageBytes 是否适合DTO,因为我对抖动的了解有限,但希望您能理解。
因此,您可以完全绕过产品汇总域存储库,并拥有另一个服务类,该类将为您提供读取/查看产品数据所需的所有数据。由于您不会通过读取数据来进行任何更改,因此不会通过域模型来进行读取优化。
构建DTO的代码将使您能够持久查询某些产品数据,还会查询Firebase来查询实际图像。如果性能存在问题,例如,如果您检索一次要读取的整个产品数据列表,甚至可以通过从UI单独调用重新加载实际的Firebase图像。