3

我有几个与设计相关的问题：

  • 应该service layer interfaces住在一个domain layer？例如user service？
  • 将代码部分移动到单独的层的主要原因是什么？
  • 应该service layer住在same assembly as the application layer？

谢谢！

编辑

我使用 aRavenDB并且有非常瘦的控制器动作，但有两个动作作为[NonAction]动作出现：

[NonAction]
public IEnumerable<Article> GetAllArticles() { 
    return this.session.Query<Article>()
        .Customize((x => x.WaitForNonStaleResults()))
        .AsQueryable()
        .OrderBy(d => d.CreatedOn);
}

[NonAction]
public IEnumerable<String> GetAllCategories() {
    return this.session.Query<Article>()
        .Select(x => x.Category)
        .Distinct().ToList()
        .OrderBy(x => x);
}

..因为我不使用存储库模式。将其放在服务中是否合理？

4

3 回答 3

3

服务层接口应该驻留在领域层吗？例如用户服务？

在 DDD 中，您必须区分两种类型的服务：域服务和应用程序服务（不包括基础设施服务）。

  • 域服务位于域层并包含不属于任何实体或跨越多个实体的域逻辑。

  • 应用程序服务位于应用程序层并定义特定于应用程序的操作，这些操作协调对域层的调用并可能返回结果。它们可能对应于用例或用例的子部分。应用程序服务由客户端直接调用，而域服务不能。

应用程序服务接口不需要在域层，因为它们不是特定于域的而是特定于应用程序的，并且域不使用它们。应用程序层引用域层，但不是相反。

将代码部分移动到单独的层的主要原因是什么？

想到的第一个好处是可重用性（在其他地方重用您的域，而不携带所有特定于应用程序的东西）和可维护性（将变化的东西组合在一起）。

请参阅关注点分离、单一职责原则、凝聚力。

服务层应该与应用层位于同一个程序集中吗？

在 DDD 中，没有服务层。不过，应用层通常等同于其他方法所称的服务层。

因为我不使用存储库模式。将其放在服务中是否合理？

“按书本” DDD 需要一个用于此类操作的存储库。即使您没有密切关注 DDD，我也不喜欢将所有东西命名为“服务”，因为有大量更准确的名称可以给它们：数据访问对象、数据网关等。这里要意识到的是，包含这些方法的对象应该放在低级数据特定层（DAL，基础设施层），因为它显式地处理一个持久数据存储（Raven DB）。

于 2012-08-09T16:04:04.240 回答
1

将代码部分移动到单独的层的主要原因是什么？

这很容易。将代码移动到您看不到的地方的主要原因是管理复杂性。当你在某个接口后面隐藏代码时，你必须只考虑那个接口，而不是它的实现。

当同样的推理涉及层时，您还有一点：层为您提供了通信限制。你有公共表面，你必须管理它，你有你实现的所有内部代码路径，你只能访问下一层（通过定义的接口集）。这有助于编写更清晰的代码。

于 2012-08-09T07:01:40.770 回答
1

如果您使用的是 .net 客户端，那就是您的存储库模式。DocumentStore 和 DocumentSession，或者它们的接口 IDocumentStore 和 IDocumentSession

于 2012-08-09T23:05:17.523 回答