这是一种为人熟知的架构风格，基本上所有开发人员都知道，软件系统需要分层设计。比较传统的常见的分层方式就是分三层：界面层、业务逻辑层以及数据访问层，各层之间会有数据传输对象（DTO）完成数据交互，以此隔离不同层内部的实现细节。领域驱动设计则将应用系统分为四层：用户界面层、应用层、领域层和基础设施层：
用户界面层：这一层比较好理解，就是直接面向用户的这一层，比如前端单页面应用或者基于MVC框架开发的前端应用。如果你的应用系统仅提供API，那么API这一层也属于用户界面层
应用层：根据领域驱动设计的描述，应用层是很薄的一层，它主要负责协调下层的执行任务，并隔离领域层与用户界面层。如果你选择采用经典分层架构，并开始实践领域驱动设计，那么在应用层你可以实现一些诸如Coordinator或者Workflow这样的组件，它们不参与任何领域或者业务相关的操作，仅仅负责协调。最常见的一种实现就是在应用层引入事务处理，有时候甚至还会跨资源实现分布式事务
领域层：你的领域模型所涉及的所有对象都会出现在这一层，如上文所述，领域层对象需要尽量避免贫血模型，开发团队与领域专家一起完成领域层的设计与开发任务
基础设施层：所有与技术细节相关的基础设施组件都属于这一层，因此，系统所依赖的数据库存储以及外部服务，都属于基础设施层。此外还有面向切面（Aspect-Oriented）的组件，比如异常处理模块、缓存模块、安全模块等等，也都属于基础设施层
在早10年以前，微软的西班牙团队在Github上开源了一套完整的基于领域驱动设计实践的分层架构案例：Microsoft NLayerApp，然而非常可惜的是，这个项目目前已经找不到了，但我仍然保留了一些资料，下图就是这个NLayerApp的架构图：
上图中红色部分代表的是用户界面层；天蓝色部分代表的是应用层；蓝色部分代表的是领域层；而绿色部分则代表基础设施层，整个软件的架构是非常清晰的，这就是一个标准的符合领域驱动设计思想的分层架构。在这个案例中，设计者引入了很多体系结构模式，比如领域层的仓储（Repository）模式和规约（Specification）模式、展现层（用户界面层）的MVC模式等，还引入了一些开发方法论，比如面向切面的编程（Aspect Oriented Programming, AOP）。从整个结构上看，它本身也就是一种架构模式：如果你选择分层架构风格，那么你就可以考虑使用上图中类似的结构来开发你的软件系统，比如引入领域模型、仓储模式、查询规约、工作流、MVC等等。当然，分层架构并不一定非要按上图中的这样去设计，你可以抛开领域驱动设计思想，自己根据项目或者产品的特点来实现分层，这是完全没有问题的，只要能够在一定的成本下，满足业务领域的需求就可以了。 在分层架构中应用领域驱动设计也是需要经过严格推敲和思考的，比如在上图中，仓储模式的实现，为什么Repository Contracts（也就是我们平时所说的仓储接口）是设计在领域层，而Repository Implementations则是放在基础结构层？原因很简单：一方面，根据上文所述，仓储的概念就是管理领域聚合的生命周期，因此它是一个领域模型中的概念，而另一方面，在实际实现当中，仓储是需要直接访问数据持久化机制的，而数据持久化机制又是与基础设施相关的组件，所以，仓储的实现部分是需要设计在基础设施层的。于是，领域模型层以及其上层的组件通过仓储接口访问仓储实例，而仓储实例则是在应用程序启动的时候通过依赖注入的形式提供。 Microsoft NLayer App已经不存在了，不过你也可以参考我在很早以前写的一个符合领域驱动设计的多层分布式架构案例：Byteart Retail，虽然目前看起来它所使用的技术相对比较老，但是整个系统的架构和各层组织结构还是非常清晰的，基本上可以比对上图的架构去阅读了解。 至此，你应该对领域驱动设计是如何在分层架构中运用已经有了一定的了解，你会发现，即使是在相对简单的分层架构中，要正确运用领域驱动设计的思想也不是一件容易的事情。你可以退而求其次，仍然选择使用分层架构，在对业务领域、研发团队、项目流程、市场反馈等等各方面进行了综合评估之后，如果你仍然选择了分层架构，而并不觉得它是一种不那么流行的架构风格的话，那么恭喜你，你或许做出了一个正确的选择。 总结起来，分层架构是相对比较简单比较容易理解的一种架构风格，实践技术也都非常成熟，有极为成熟的案例可以参考，如果你的软件系统业务本身并不复杂，而且在将来的一段时间内业务扩展不会特别大（比如为学校图书馆开发一套图书馆管理系统），而你的团队对于分层架构也更为熟悉的话，它的确是一个不错的选择。但是，如果你的软件所要处理的业务比较复杂，而且今后业务会不断扩展变大，那么庞大的业务体量将会使得你的业务逻辑层变得臃肿复杂，从而引起系统难以维护、代码构建时间过长、组件关联错综复杂、系统性能逐渐降低等等一系列问题，在这种情况下，你或许更应该选择微服务架构风格。但不管怎么选，由领域驱动设计所指导的领域建模实践以及相关的体系结构模式，都可以使用在（或者不使用在）你所选择的软件架构之中。 分层架构大致就介绍这么多吧，接下来介绍一下一种比较流行的架构风格：事件驱动型架构。
事件驱动型架构（Event-Driven Architecture）