我从事一个项目，我们尝试尽我们所知应用 DDD。我们还使用 CQRS 和洋葱架构。 我们有聚合，我们有存储库。对于每个帖子，我们使用工厂服务，然后使用聚合存储库保存结果，当然，我们在不使用任何工厂的情况下调用存储库。 到目前为止一切顺利!
现在，对我来说有点可疑，但我很好奇听到其他意见:对于某些获取，由于性能问题，我们不希望加载整个聚合，而不是使用域模型例如，获取 5 个字段，因此我们绕过域模型，并为该 CQRS 查询使用单独的存储库。这个存储库(我们称之为搜索引擎)返回一个 DTO(不是普通存储库返回的域模型)。我们绕过整个域，一切都发生在应用程序层。
这正常吗？这个臭吗？这看起来像是我们的领域模型设计不正确吗？这是不好的做法吗？这符合 DDD 和整洁的架构吗？
我很想听听你的想法
最佳答案
在现代设计中，响应安全请求时绕过域模型是正常的。
从历史上看，当 Evans 描述实现模式时，“数据库”只是隐藏在存储库抽象后面的一些实现细节。因此，对数据的访问受到存储库接口(interface)提供的内容的限制；这意味着聚合根，或聚合根的集合。
您可以在 Cargo Booking sample 中看到这一点，其中存储库提供聚合根列表，然后该根列表将转换为 DTO 列表。
我将此归因于 Evans 在 2003 年左右从事 Java 工作；有一堆隐含的约束，它们没有比当时“这就是我们认为好的面向对象设计的样子”更真实的理由。
公平地说，您希望将读取模型基于写入模型将使用的数据并不是完全不合理的。写入模型预计会根据业务需求而改变；如果我们希望 View 能够代表模型，那么 View 将需要进行相同的更改，并且更容易确保一个 View 是否直接依赖于另一个 View 。
随着分布式域驱动设计(最终成为命令查询责任分离)的引入，我们开始放弃“聚合”支持安全查询的概念。如果您想查询数据，您可以询问数据库 - 这就是数据库的用途。
域模型的单一职责是管理对数据库中存储的信息的更改。
关于domain-driven-design - DDD : Should we bypass domain models sometimes?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56867065/