我有一个域实体ProjectEstimate，它知道如何计算自己的估算货币金额。这是基于对象本身上可用的多个固定值的简单计算。 Calculate方法被称为业务逻辑的一部分，并且EstimateCost字段已用金额更新。那里没有什么难的。
但是，现在计算逻辑的复杂度大大增加，并且已成为第三方HTTP API调用的背后因素，而我正在努力寻找如何在不违反域“纯度”的前提下对该API进行调用及其逻辑。
我很乐意采用双调度方法来调用域服务，但是即使这样，我也对如何放置逻辑来调用第三方API提出了疑问。
我正在努力找出如何对该API进行调用，而又不会违反域的“纯度”及其逻辑。
我有两种常见的模式。
他们共有的部分是在API调用的语义及其实现之间创建抽象边界。就是说，我们将创建一个看起来像一个函数的外观。它使用一些值作为参数并返回一个值。
此模式应该感觉很熟悉，因为它类似于存储库模式，在该模式下，我们展示了简单的收集/缓存语义，并在幕后隐藏了一些持久性实现细节。
现在有了外观，通常以两种方式之一使用它。
“简单”的方法是将外观作为参数传递给领域模型。就模型而言，它只是一个域服务，必要时可以调用或不调用它。
替代方法是与应用程序组件中的立面进行交互；从域模型中读取函数参数，从外观中获取结果，然后将结果传递回域模型。最后，您将职责分离得更加清晰了-域模型知道该怎么做，应用程序知道该怎么做。
Cory Benfield关于protocol libraries的演讲是第二种方法的一个很好的起点。