Question

我有一些与设计相关的问题：

应该service layer interfaces位于domain layer吗？例如user service？
将代码部分移动到单独的图层的主要原因是什么？
应该service layer位于same assembly as the application layer？

谢谢！

修改

我使用RavenDB并且具有非常瘦的控制器操作，但是[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);
}

..因为我没有使用存储库模式。把它放在服务中是否合理？

Answer 1

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

在DDD中，您必须区分两种类型的服务：域服务和应用程序服务（不提及基础结构服务）。

域服务位于域层中，包含不属于任何实体或跨越多个实体的域逻辑。
应用程序服务位于“应用程序”层中，并定义特定于应用程序的操作，这些操作可协调对“层”层的调用并可能返回结果。它们可以对应于用例或用例的子部分。应用程序服务由客户端直接调用，而域服务不能。

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

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

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

请参阅Separation of concerns，Single Responsibility Principle，Cohesion。

服务层应该与应用程序驻留在同一个程序集中层

在DDD中，没有服务层。但是，应用层通常与其他方法称为服务层的方法相同。

因为我没有使用存储库模式。把它放进去是否合理服务？

“通过本书”DDD将需要一个存储库来进行此类操作。即使你没有密切关注DDD，当有大量更准确的名字给它们时，我也不是把所有东西命名为“服务”的忠实粉丝：数据访问对象，数据网关等等。这里要实现的是，包含这些方法的对象应放在低级数据特定层（DAL，Infrastructure层）中，因为它明确地处理一个持久性数据存储（Raven DB）。

Answer 2

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

这个很容易。将代码移动到您无法看到的地方的主要原因是管理复杂性。当您隐藏某些界面后面的代码时，您必须只考虑该界面，而不是其实现。

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

Answer 3

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

服务层设计。将事物放入服务层的原因

3 个答案: