实现域服务作为存储库的扩展方法

Question

我对领域服务的理解是，它们执行相关存储库边界之外的任务（CRUD 相关任务）。

既然 .Net 允许扩展方法，为什么不将域服务实现为存储库的扩展方法，从而减少在需要时实例化存储库和服务的需要呢？

如果有任何意见，我将不胜感激。

Answer 1

“我对领域服务的理解是，它们执行相关存储库边界之外的任务（CRUD 相关任务）。”

你的理解和我的不一样，是：

域服务用于封装落在单个聚合/实体/值对象边界之外的域逻辑。

存储库关注的是存储，而不是领域逻辑，因此两者是非常不同的东西。

老实说，我在这里看到的有关域服务的问题越多，我就越觉得人们对域服务的实际含义普遍感到困惑。我认为这可能是由于以下内容之间的模糊性造成的：

1. 应用程序服务 - （UI 调用的内容和事务开始的位置）
2. 基础设施服务 - （例如 IEmailSenderService、ICreditCardPaymentGateway 之类的东西）
3. 域服务 - （提供纯域逻辑，就像聚合/实体）

Jimmy Bogard 编写了 关于他们独特角色的好文章。

所以回答你的问题：这是一个坏主意，因为你会混淆两个非常不同的概念，并且会违反 建议零售价

Answer 2

第一个问题是您的对象将充满基础设施方法。

其次，您必须为这些包含扩展方法的静态类添加另一层，恕我直言，这将分散您的服务层和域模型的代码。

第三，您必须通过标记接口对对象进行分类，以过滤它们能够调用的方法。

另一个问题是执行的上下文，当您在对象上调用 CRUD 方法时，它将在客户端或服务器端执行？

此外，还违反了持久性无知域模型，

最后一点是，在 ORM 中，保存的不是单个对象，而是保存的会话，回想一下 工作单元 模式。

Answer 3

域服务很可能使用多个存储库。例如同时存在客户和订单存储库。

所以我认为这是一个坏主意。

Answer 4

正如 DDD 中所指定的，服务是无状态方法（或者，在 OO 世界中，是一类相关方法），因此最终，扩展方法确实符合要求。

在存储库上使用扩展方法的最终结果将是从存储库公开服务接口，同时在存储库外部定义实现（这很好地减少了存储库的传出耦合）。通过使用委托模型定义服务方法，可以以更“OO 友好”的方式实现类似的结果（在 .Net 3.5 及更高版本中，您可以利用 Func<> 和 Action< >），其中委托实现在其他地方定义（并且可以通过 基于委托的工厂）。

public class MyRepository
{
    //Repository Specific Methods
    public DomainObject FindById(...)
    ...

    //"Service" Methods as Delegates
    public Func<DomainObject, SomeResult> ProcessDomainObjectAndGetBackSomeResult
    {
        get
        {
            return ServiceMethodFactory.ProcessDomainObjectAndGetBackSomeResult;
        }
    }
}