从存储库( DDD )获取可能需要的数据

Question

我们(大致)有以下架构：

基础设施应用程序服务负责从隐藏在interfaces.

• Object图后面的存储库中获取数据，并将其传递给适当的域service.

• Domain服务，进行处理并引发适当的事件，在执行一些持久操作(更改存储库、发送电子邮件等)的不同应用服务中处理

• 事件。

然而。域服务(3)变得如此复杂，只有在满足特定条件时，它才需要来自不同外部API的数据。例如，如果产品X是汽车类型的，我们需要从隐藏在ICatalogService后面的外部CatalogService (例如发明的)了解该车型的价格。这个操作可能很昂贵(REST调用)。

我们该怎么做？

我们是否预先获取应用服务中列出的(1)所有数据，即使我们可能不需要它？我们是否将接口ICatalogService注入到给定的域服务中，并仅在需要时获取数据？如果某个域服务的其他客户端在不知道存在REST调用的情况下重复调用此域服务，则后一种解决方案可能会产生性能问题。

还是我们只是简单地弄错了域模型？

这个问题与领域驱动设计有关。

Answer 1

，我们该怎么做？

有两种常见的模式。

一种是将查询传递到域模型中，允许模型在需要时自行获取信息。这通常是定义一个接口/契约，该接口/契约将由域模型使用，但在应用程序/基础结构层中实现。

二是扩展域模型与应用程序之间的协议，向应用层发送所需信息，然后由应用程序代码决定如何提供信息。您将得到类似于进程的状态机的东西，应用程序代码协调外部api和域模型之间的信息交换。

如果您使用一点想象力，您已经有了这样一个状态机；因为您的应用程序代码已经在协调输入到存储库和域模型的移动。当然，区别在于现有的“状态机”足够简单和线性，因此可能根本不存在状态机。

你到底会给应用层发什么信号？

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

Answer 2

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

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