Domain driven design 同一域模型的多个数据传输对象

根据一个视图，当同一对象有多个表示时，如何解决这种情况

例如，假设你有一家书店。在书店中，您有两种主要的书籍表示形式：

在列表中（搜索结果、按类别浏览、作者等）：这是一种紧凑的表示形式，可能包含一些聚合，例如NumberOfAuthors和NumberOfRwviews。每个作者和评论都是保存在数据库中的实体

DetailsView：在这里，每个作者都没有聚合，而是实际值，因为这本书有一个属性AuthorsList

案例2很清楚，您可以从DB获得所有信息并显示出来。但如何解决案例1。如果要减少与DB之间的连接数和有效负载？所以，如果您不想从DB获得所有实际的作者和评论，那么每个人只需要2个整数

完全规范化的解决方案应该是2，但1似乎需要一些非规范化，或者在业务层中创建两个不同的实体：BookDetails和BookCompact

---

重要提示：我说的不是视图DTO，而是从DB中获取数据，而DB不适合业务层图书类。

对我来说，这听起来像是多查询模型（QM）。 我使用了带有CQRS/ES风格的DDD，因此聚合根根据传入的命令生成事件。向这些事件订阅了多个QMs。因此，我根据需求创建多个“视图”。
ES（事件源）功能强大——我可以稍后通过重放存储的事件来引入另一个QMs。
听起来像是在管理大量相似甚至重复的数据，但对我来说很有意义。

---

QMs可以并且经过优化，只包含足够的数据/结构/索引以满足给定的目的。这就是“共享数据模型”的出路。我看到了“RDMS”一对一方法的巨大弊端。您总是会迷失在管理共享模型的复杂性中—就像您一样。

我使用以下设计获得了非常好的结果：

• 域

  包包含

  @实体

  类，这些类包含存储在数据库中的所有必要数据

• dto

  包含从服务返回的实体视图的包

Dto应该具有以实体为参数的构造函数。为了更容易地复制数据，您可以使用

BeanUtils.copyProperties（domainClass、dtoClass）

通过这样做，您只共享了最少量的信息，并且返回的对象没有任何功能。
这很简单，不使用域模型进行查询。直接转到数据库。读和写是两件不同的事情。聚合用于写，而不是读。我不确定我是否正确阅读了您的评论，但可能有误解。对于读和写，我确实有单独的DTO/DAO，但目前我根本不讨论写，只讨论读。所以，这是关于当你有两种不同的阅读时的情况；不同之处在于Read1是Read2的子集（因为它只需要部分数据）。在这种情况下，每个read是否应该有自己的业务模型表示，或者评论的集合实际上应该是服务层中的方法GetReviews（int bookId），而不是业务模型实体上的属性？“每个read都有自己的业务模型表示”这是我没有得到的部分。Reads根本不应该关心业务模型（域模型）。您向数据库发出一个查询，以准确收集所需内容，然后根据结果构造DTO。就这样。你可以一起编写多个DTO。好吧，我现在明白你的意思了。正如我所说，任何不参与业务不变量检查的计算数据都不必是域模型的一部分（但它可以）。基本上，计算最长条纹可以很容易地在查询端完成，而根本不涉及域。但是，如果逻辑过于复杂，则可能值得将该逻辑保留在域模型中，并在保持计算结果的同时通过侦听域事件使其保持最新。不过，价格示例可能有所不同，因为价格很可能会在业务流程中使用（例如，购买书籍）。您可能希望能够确保其计算中涉及的任何数据在计算价格和购买产品的时间之间不会发生变化（或者最终的一致性很好，或者是考虑到所涉及的数据量，这是唯一的方法）。因此，如果我读对了，您的意思是一个查询模型用于列表中的视图，另一个用于详细视图？如果是这样，那么我有两个问题：1）你把这两个质量管理体系放在哪里？它们是域的一部分还是？2） 如果在这两种模型上都应用了业务逻辑，那么您将在何处使用它？是2个聚合继承了相同的抽象聚合吗？或者你的服务层中的什么东西？还是其他方式？感谢1）QM它们是CQRS的查询部分。2）业务逻辑应该在命令处理时执行。这会导致事件的发生。事件由QMS使用基本上是。它的活动来源风格。检查axon，它包含许多实现的基础设施功能，以支持CQRS/ES风格的DDD。持久性不是冗余的，它不是共享的rdms存储。它尊重单一责任原则——事件按原样存储，多个QMs包含对每个人都很重要的数据，而不是更多，命令模型包含的数据仅足以进行业务决策。而EventStorage包含了系统中发生的一切，所以它掌握了真相，可以用来从头开始重建系统，进行业务分析，这样的系统中有巨大的力量。在共享关系数据库中，您并没有数据的最新快照，您从第一天起就有了完整的系统行为。使用ES的另一个场景是，y