从存储库中获取可能需要的数据-DDD

如何解决从存储库中获取可能需要的数据-DDD

（大致）我们拥有以下架构：

1. 应用程序服务完成基础结构工作-从隐藏在接口后面的存储库中获取数据。
2. 对象图已创建并传递到适当的域服务。
3. 域服务执行此操作并引发适当的事件。
4. 事件在执行某些持久性操作（更改存储库，发送电子邮件等）的不同应用程序服务中处理。

但是。域服务（3）变得如此复杂，以至于只有满足特定条件时，它才需要来自不同外部API的数据。例如，如果产品X的类型为Car，那么我们需要从隐藏在ICatalogService后面的某些外部CatalogService（发明的示例）中知道该汽车模型的价格。此操作可能很昂贵（REST调用）。

我们该如何处理？

A。我们是否会在不需要的情况下预取列在（1）中的Application Service中的所有数据？我们是否将接口ICatalogService注入给定的域服务中，并且仅在需要时才获取数据？如果域服务的其他客户端在不知道其内部隐藏了REST调用的情况下重复调用此域服务，则后一种解决方案可能会导致性能问题。

还是我们只是错误地将域模型弄错了？

此问题与域驱动设计有关。

解决方法

我们该如何处理？

有两种常见的模式。

一种方法是将 capability 传递给域模型，以使模型可以在需要时获取信息本身。通常，这看起来像是定义一个接口/一个合约，该合约/合约将由域模型使用，但在应用程序/基础架构层中实现。

另一种方法是在域模型和应用程序之间扩展协议，以便我们可以向应用程序层发出需要什么信息的信号，然后应用程序代码可以决定如何提供它。最后，您将得到一个类似于状态机的流程，而应用程序代码将协调外部api和域模型之间的信息交换。

如果您有一些想像力，那么您已经有了类似这样的状态机；因为您的应用程序代码已经在协调向存储库和域模型的输入移动。当然，区别在于，现有的“状态机”非常简单且线性，以至于根本不存在一个状态机。

您将如何准确地向应用层发送信号？

简单查询；也就是说，应用程序代码将所需的信息从域模型中拉出，并使用该信息来计算下一个动作。操作完成后，应用程序代码会将信息推送到域模型。

,

没有足够的信息可以给您有针对性的好的建议。我怀疑您需要将您的域重构为更多子域。听起来您的域服务有多种责任。保持服务简单。

此外，如果您的任务很长时间，例如服务调用需要很长时间，那么您就需要对其进行架构设计。最柔软的设计不会让消费者久等。即使只是定期更新状态，它也会立即以某种结果返回给用户。