Domain driven design DDD：我们有时应该绕过域模型吗？

我在一个项目中工作，在这个项目中，我们尽最大努力应用DDD。我们还使用CQR和onion架构。 我们有聚合，我们有存储库。对于每一篇文章，我们使用一个工厂服务，然后使用聚合存储库持久化结果，对于put，我们调用存储库，当然不使用任何工厂。 到目前为止还不错

现在，对我来说，smth是可疑的，但我很好奇听到其他的观点：对于一些get，由于性能问题，我们不想加载整个聚合来获得5个字段，例如，因此我们绕过了域模型，我们只为CQRS查询使用单独的存储库。这个存储库（我们称之为搜索引擎）返回一个DTO（而不是普通存储库返回的域模型）。我们绕过整个领域，一切都发生在应用层。

这正常吗？这气味难闻吗？这看起来像是我们的领域模型没有正确设计吗？这是坏习惯吗？这是否符合DDD和clean体系结构？

---

听到你的想法我很好奇

在现代设计中，在响应安全请求时绕过域模型是正常的

从历史上看，当Evans描述实现模式时，“数据库”只是隐藏在存储库抽象背后的一些实现细节。因此，对数据的访问受到存储库接口提供的内容的限制；这意味着聚合根，或聚合根的集合

您可以在中看到这一点，其中存储库提供了聚合根的列表，然后根的列表被转换为DTO的列表

我认为这是因为Evans大约在2003年研究Java；有一堆隐含的约束，没有比“我们当时认为好的OO设计就是这样”更真实的理由

公平地说，您希望将读模型建立在写模型将使用的数据的基础上并非完全不合理。写入模式预计将根据业务需求而改变；如果我们希望视图能够代表模型，那么视图将需要进行相同的更改，并且如果一个视图直接依赖于另一个视图，则更容易确保

随着分布式域驱动设计（最终成为命令查询责任分离）的引入，我们逐渐放弃了“聚合”支持安全查询的概念。如果你想查询数据，你需要一个数据库——这就是数据库的用途

---

域模型的唯一职责就是管理数据库中存储的信息的更改。

谢谢！这是有道理的