domain-driven-design - 不禁将域实体视为浪费。为什么？

Question

当我阅读了有关 DDD、模式和许多其他应用程序架构主题的文章时，我有一个问题一直困扰着我数月之久。我将根据 MVC Web 应用程序来构建它，但我敢肯定，问题是更广泛的。就是这样:遵守领域实体是否会在应用程序中造成僵化和低效？

DDD 方法对于管理应用程序的业务逻辑以及作为与利益相关者合作的一种方式非常有意义。但对我来说，它在多层应用程序的上下文中分崩离析。也就是说，很少有场景需要一个实体的所有数据，或者甚至两个存储库都拥有这一切。就其本身而言，这还不错，但这意味着我进行了多个查询，返回了一堆我不需要得到的一些属性。一旦完成，无关信息要么被传递到 View ，要么存在丢弃、合并和映射数据到 DTO 或 View 模型的开销。我需要生成大量报告，并且问题似乎在那里被放大了。每个都需要对信息进行独特的切片或聚合，SQL 可以做得很好，但存储库不能，因为它们预计会返回完整的实体。老实说，这似乎很浪费，原则上我不想破坏数据库并产生不需要的网络流量。从这样的问题 Should the repository layer return data-transfer-objects (DTO)?似乎我不是唯一一个为这个问题而苦苦挣扎的人。那么它似乎强加的限制的答案是什么？

感谢一个新的和困惑的 DDD-er。

Answer 1

这里真正的问题是什么？处理业务规则和查询数据是两个截然不同的问题。这种认识将我们引向了 CQRS——命令-查询职责分离。那是什么？您只是不要对这两个任务使用相同的模型:领域模型是关于行为、执行业务流程、处理命令的。并且有一个单独的报告模型用于显示。通常，每个 View 可以包含一个表。这些表只包含相关信息，因此您可以摆脱 DTO、AutoMapper 等。

这两个模型如何同步？它可以通过多种方式完成:

• 报告模型可以建立在数据库 View 之上
• 数据库复制
• 域模型可以发出包含有关每个更改的信息的事件，并且它们可以由非规范化程序处理，更新报告模型中的适当表格