我正在从事一个项目，在该项目中，我们尝试根据我们的知识应用DDD。我们还使用CQRS和洋葱架构。 我们有其存储库的聚合。对于每个帖子，我们使用工厂服务，然后使用聚合存储库保留结果，例如，当然，我们不使用任何工厂就调用存储库。 到目前为止一切顺利！
现在，这里对我来说有些混乱，但我很想听到其他意见：对于某些方面，由于性能方面的考虑，而不是使用域模型，我们不想将整个聚合加载到例如获得5个字段，因此我们绕过域模型，而仅针对该CQRS查询使用单独的存储库。该存储库（我们称其为搜索引擎）返回DTO（而不是普通存储库返回的域模型）。我们绕过整个领域，一切都在应用程序层进行。
这正常吗？这臭吗？看起来我们的域模型设计不正确吗？这是不好的做法吗？这符合DDD和干净的体系结构吗？
我很想听到你的想法
答案 0 :(得分：3)
在现代设计中，响应安全请求时通常会绕过域模型。
从历史上看，当Evans描述实现模式时，“数据库”只是隐藏在存储库抽象后面的一些实现细节。因此，对数据的访问受到存储库接口所提供内容的限制。表示聚合根或聚合根的集合。
您可以在Cargo Booking sample中看到这一点，其中存储库提供了聚合根列表，然后该根列表转换为DTO列表。
我将其归因于Evans大约在2003年从事Java开发。当时有一堆隐含的约束没有比“当时我们认为好的OO设计看起来像”更真实的理由。
说句公道话，让读取模型基于将由写入模型使用的数据并不是完全不合理的。预期写模型会根据业务需求而改变；如果我们希望视图能够代表模型，那么视图将需要进行相同的更改，并且确保一个视图直接依赖于另一个视图要容易得多。
随着分布式域驱动设计的引入（最终成为命令查询责任分离），我们放弃了“聚合”支持安全查询的概念。如果要查询数据，请询问数据库-这就是 的数据库。
域模型的唯一职责就是管理对数据库中存储的信息的更改。