Domain driven design DDD中效用类的放置

我正试图找出在基于DDD的项目中把我的实用程序类放在哪里。案例如下：

---

我有一个名为CookieAwareWebClient的类，它是核心工作所必需的。从我在线阅读的内容来看，这似乎是属于基础架构层的一个类，但是不应该从核心层引用基础架构层。这意味着我不能将核心层所依赖的功能放在基础架构层中。那么这个CookieAwareWebClient类应该放在哪里呢？

如果不完全理解您需要做什么，我相信@plalx在评论中总结了这一点：

• 建立一个接口，提供核心层所需的功能
• 在CookieAwareWebClient中实现此接口
• 使用依赖项反转允许核心使用CookieAwareWebClient

以下是一些以构造函数注入为例的代码（在本例中为C#）：

界面：

namespace Core
{
  public interface IBlah
  {
    int SomethingCoreNeeds();
  }
}

CookieAwareWebClient的实现：

namespace Services
{
  public class CookieAwareWebClient : IBlah
  {
    // ... rest of class 
    private int _somethingCookieAwareWebClientHasThatCoreNeeds;

    public int SomethingCoreNeeds()
    {
      return _somethingCookieAwareWebClientHasThatCoreNeeds;
    }
    // ... rest of class 
  }
}

核心消费服务：

namespace Core
{
  public class DomainService
  {
    private readonly IBlah _blah;

    public DomainService(IBlah blah)
    {
      _blah = blah;
    }

    public void DoSomething(DomainEntity entity)
    {
      entity.NeededValue = _blah.SomethingCoreNeeds();
    }
  }
}

---

这个名字听起来显然是基础设施的一部分。如果不进一步了解您的代码和应用程序，我会说，当您的核心依赖于此类时，您会遇到设计问题。@Jehof对此类的依赖源于核心层中的服务类，该服务类从API检索数据并将所述数据返回给调用应用程序。我认为在这种情况下，存储库只会过度。你怎么看？CookieAwareWebClient用于调用核心所依赖的外部服务。是吗？是的。它用于连接到API并从所述API返回数据。我的核心中的服务基本上是这个API的包装器。您的域模型和这个服务之间的关系是什么？通常，您会在域模型中声明一个接口，并在基础架构层实现它，就像使用存储库模式一样（这是依赖项反转原则）。这些服务通常由应用程序服务而不是域使用。例如，存储库很少从实体中使用。如果可以，让应用程序层解决依赖关系，但如果这不可行，则始终可以在方法级别将服务注入实体。使用接口隔离有助于解决问题。