Domain driven design 应用程序层和基础结构层之间的依赖关系存在一些混淆 当应用程序使用存储库（它是一种基础结构服务）时，存储库接口在域层中定义，而其实现在基础结构层中定义，因为这样域模型就没有传出依赖项

a） 如果我们100%确定某个特定的（非存储库）基础设施服务InfServ永远不会被域层中的任何代码调用，那么我假设InfServ的接口不需要在域层中定义

假设域层中的代码不会调用InfServ（因此，我们不需要在域层中定义其接口）：

a） 如果应用层的服务将调用InfServ，我假设应用层应该对基础架构层具有隐式依赖，而不是相反？换句话说，InfServ的接口及其实现都应该在基础架构层中定义

b） 应用程序层最好依赖于基础架构层，而不是另一种方式，原因是基础架构层可以被许多应用程序重用，而应用程序层在大多数情况下只针对单个应用程序，通常不能被其他应用程序重用

c） 如果我们100%确定域层中的任何代码都不会使用存储库，那么我们就不需要在域层中定义它的接口了

更新：

(一)

是的，但是，域层的定义可以包括应用程序 在域上充当门面的服务。应用程序 服务通常引用存储库和其他基础设施 服务。它协调要实现的域对象和所述服务 用例

（a）

。。。作为域上的门面

难道我们不能说“常规”（我在问题中提到的那些）应用程序服务也充当域的门面吗

（b）

应用程序服务通常引用存储库和其他 基础设施服务

从您的回复中，似乎您是在建议（尽管您可能不是）常规应用程序服务通常不引用基础设施服务，而事实上它们确实引用了基础设施服务（据我所知）

(二)

（a）

如上所述，我通常将应用程序服务合并到 域层

“常规”应用程序层也是BLL层的一部分，所以我们能不能说它与域层合并（它实际上位于域层之上）

（b）

我倾向于坚持六边形建筑风格

六边形架构似乎没有应用层（即应用服务）的明确概念

（c）

在域中声明存储库接口的部分好处 层是指定域的数据访问要求的层

所以我们应该在域层中包含存储库接口，即使域代码不使用它

第二次更新：

2a）

如果您所称的“常规”应用程序服务与 域，我认为将其作为域的一部分是可以接受的 “层”。但是，域不应直接依赖于 周围的应用程序服务，因此可以将它们拆分 如果需要，可将其分为单独的模块

• 我不确定您是否暗示应用程序层（在传统分层体系结构中）的设计与您使用洋葱体系结构将应用程序层与域层合并时有什么不同

• 我想说，至少就模块而言，这两个模块不应该有所不同，因为在这两种情况下，我们可以分离应用程序层模块和域层模块？（尽管我必须承认，我跳过了《陪伴》模块（埃文的书），因为我认为在学习DDD:O的这么早我就不需要这些知识了）

2b）

是的，因为它可以与分层体系结构形成对比。严格的 分层体系结构不符合声明的思想 域层中的存储库接口及其在中的实现 基础设施层。这是因为，一方面，你有 在一个方向上的依赖关系，但在部署方面的依赖关系 在另一个。Hexagon通过放置 位于中心的域。看看洋葱的架构——它是 基本上是六边形的，但可能更容易掌握

我还不知道MVC模式或Asp.Net MVC，但不管怎样，从阅读本系列的前三部分（这让我感到困惑，以至于我不再阅读它）来看，似乎：

a） 发件人：

每一层都耦合到它下面的层，并且每一层通常是 再加上各种基础设施问题

作者的意思是，在传统的分层体系结构TLA中，域层与基础结构层耦合，这肯定不是真的，因为我们通常在域层中定义基础结构接口（如存储库接口）

b） 若在使用TLA时，我们决定在应用层定义基础设施接口，那个么应用层也不耦合到基础设施层

c） 洋葱架构不是一个*基础架构层*耦合到应用程序核心（包括应用程序层），因为基础架构接口是在应用程序核心中定义的吗

d） 如果对c）的回答是肯定的，那么将应用程序层与基础架构层耦合（出于我在原始问题中给出的原因（这里我假设域层不会调用基础架构服务））不是更好吗

(四)

发件人：

域模型周围的第一层通常是 查找接口

class Foo
{
           ...
       public int DoSomething(IRepository repo)
       {
              ...
            var info = repo.Get...;
              ...
       }
}