将外部数据源封装在存储库模式中

Question

我正在为一项新服务创建高级设计。服务的复杂性需要使用 DDD（我认为）。所以我做了常规的事情并创建了域服务、聚合、存储库等。我的存储库封装了数据源。因此，查询可以在缓存中查找对象，如果在数据库中查找失败，则调用REST外部服务来获取所需信息。这是相当标准的。现在我的同事提出的论点是，以这种方式抽象数据源是危险的，因为使用存储库的开发人员将不知道执行 api 所需的时间，因此无法计算他所访问的任何 api 的执行时间。上面写着。如果他知道他的调用会导致调用，他可能会想要以不同的方式设置他的组件的行为REST。他们建议我将调用移到REST存储库之外，甚至可能将缓存策略也随之移出。我可以理解他们的观点，但存储库模式背后的整个想法正是隐藏此类信息，而不是让每个组件处理缓存策略和数据访问。我的问题是，是否有一种模式或模型可以解决这个问题？

Answer 1

他们建议我将 REST 调用移到存储库之外

那么你将没有存储库。存储库意味着我们不知道持久化细节，并不是说我们不知道持久化的存在。每次我们使用存储库时，无论其实现如何（从内存列表到 REST 调用），我们都期望“缓慢”，因为众所周知，持久性通常是瓶颈。

使用某个存储库实现（例如基于 REST 的）的人会知道它将处理延迟和瞬态错误。仅具有依赖关系的服务IRepository仍然知道它处理持久性。

关于缓存策略，您可以拥有一些服务级别（更通用）缓存和存储库级别（特定于持久性）缓存。这些可能应该是实现细节。

现在我的同事提出的论点是，以这种方式抽象数据源是危险的，因为使用存储库的开发人员将不知道执行 api 所需的时间，因此无法计算他所访问的任何 api 的执行时间。上面写着。如果他知道他的调用将导致 REST 调用，他可能会想要以不同的方式设置他的组件的行为。

这是浪费时间试图让你的生活变得复杂。抽象的全部意义在于隐藏肮脏的细节。他们的建议基本上是：让用户了解一些实现细节，以便用户可以将其代码与其结合起来。

关键是，开发人员应该了解他们正在使用的 API。如果组件正在使用外部服务（数据库、Web 服务），则应该知道这一点。一旦您知道要获取数据，您就知道必须等待它。

如果您采用 DDD 路线，那么您就拥有了有界上下文 (BC)。让一个模型依赖于另一个 BC 是一个非常糟糕的主意。每个 BC 应该发布领域事件，每个感兴趣的 BC 应该订阅并基于这些事件保留自己的模型。这意味着查询将是“本地”的，但您仍然会访问数据库。