将域服务实现为存储库的扩展方法答案

【问题标题】：Implement Domain Services as Extension Methods for the repository将域服务实现为存储库的扩展方法
【发布时间】：2012-05-18 16:52:59
【问题描述】：

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

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

我会很感激任何 cmets。

【问题讨论】：

我已经考虑了一段时间 :-)
定义服务类似乎有点矫枉过正，但我承认这种愿望。我认为使用扩展方法实现服务可以带你去 DDD 推荐的地方，但把形式抛在脑后。

标签： c# design-patterns domain-driven-design

【解决方案1】：

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

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

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

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

老实说，我在这里看到的关于域服务的问题越多，我就越觉得围绕域服务实际上是什么存在普遍的混淆。我认为这可能是由于以下之间的歧义：

应用程序服务 - （UI 调用什么以及事务开始的位置）
基础设施服务 - （例如 IEmailSenderService、ICreditCardPaymentGateway）
域服务 - （提供纯域逻辑，就像聚合/实体一样）

Jimmy Bogard 写了一封 good article 来介绍他们的独特角色。

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

【讨论】：

【解决方案2】：

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

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

第三是你必须对你的对象进行分类，例如标记接口来过滤他们能够调用的方法。

另一个问题是执行的上下文，当你在一个对象上调用一个 crud 方法时，它会在客户端还是服务器端执行？

另外就是违反了持久化无知领域模型，

最后一点是，在 ORM 中，不会保存单个对象，而是会保存会话，回想一下 Unit of Work 模式。

【讨论】：

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

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

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

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

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

【讨论】：