只是一些个人经验，我使用的是 Eric Even 的 DDD 书中提到的这个架构：
简而言之：
1) 接口由负责与用户（真正的端点用户或远程机器）、web mvc 控制器、web 视图对象、远程外观等交互的组件组成。
2) 应用程序定义了您的系统提供的功能。我认为它与接口层高度耦合。如果在 Application 中定义方法，通常还需要添加 Interfaces 类/方法。但是多个接口类/方法可能依赖于同一个 Application 对象，例如，您同时提供 web ui 和 web 服务用于下订单。
3) 域，系统中最稳定的部分。例如，在语言上下文中，单词/句子是具有自己含义的域对象，我将它们组织起来形成这个答案。因此，您可以将我视为 Application 对象，尽管不是一个好的对象，因为我不会说流利的英语：P
4) Infrstructure，其实我不认为这是一个层，它实现了以上三个。例如，您在域层中有一个接口 OrderRepository，您可以使用一些 orm 框架（持久性基础设施）来实现它。我的大部分基础设施对象都是适配器（在 Application/Domain/Interfaces 层实现接口并适应外部组件，如数据库、消息传递提供程序、邮件服务器等）。
希望这会有所帮助。
基础设施意图更新：
这是我们项目的包视图之一。
基础设施层有一些适配器：
1.infrastructure.channel.XXX 每个包都包含几个特定在线支付提供商的适配器。
2.infrastructure.payment 包含我们组织的支付系统的适配器，但它位于另一个有界上下文中。我们使用 MakePaymentService（一种域服务）将支付系统与该系统的其他部分解耦。
3.infrastructure.messaging 包含消息传递提供者的适配器，我们为 PaymentWasMadeNotifier（应用服务）提供了一个 jms 实现
4.infrastructure.persistence 包含数据库适配器，我们为 Domain Repositories 提供 iBATIS（Java 中的 orm 框架）。
以上这些适配器都在Application/Domain层实现了一些接口。
下面是一些“服务”，但它们是通用的：
5.infrastructure.mail
6.infrastructure.logging
7.infrastructure.security
上面的这些包暴露了一些接口和实现。例如，我们提供了一个 MailManager 接口，它与特定功能无关。主题、内容取决于应用层/领域层。我们在同一个包中提供了一个使用 javamail 的实现。
public interface MailManager {
void send(String subject, String content);
}
8.infrastructure.time 这个很特别，我们在这个系统中有一些 cron 工作，所以我们引入了一个 Clock 来将时间与工作设置解耦，因此它对测试很友好（想象一下我们有一个工作，它应该在每个月的25号启动，我们可以通过将当前时间设置为25号来测试作业，即使是今天的1号）。我们在持久化包中提供了一个实现（由于某些原因，我们需要在生产中使用数据库的时间）
public interface Clock {
Date now();
}
所以我的理解是：基础设施为您的其他三层提供服务/实现，但它们是特定于技术的。例如，主题、内容、发件人、收件人、cc 是邮件上下文中的域模型，但它们是您的域上下文中的基础设施。基础设施层为您将它们分开。