《DDD 分层架构的三种模式》是作者在领域驱动设计峰会 2017上的演进话题，同时也是作者当年在简书上写的一篇热门文章。经过这几年的沉淀，作者对 DDD 分层架构有了更深入的思考和实践，想通过本文将核心知识点和实践经验传播给更多对分层架构有意愿精进的同学，从而大家一起升级到 2.0 版本。
本文主要有四个部分的内容，如下图所示：
分层架构介绍
分层架构是运用最为广泛的一种架构模式，几乎每个软件系统都需要通过分层来隔离不同的关注点，以应对不同需求的变化，并且使得这种变化可以独立进行。
对于分层架构来说，层次越往上其抽象层次就越面向业务和用户，层次越往下其抽象层次就越面向技术和设备。
经典三层架构
分层架构由来已久，把一个软件系统进行分层，似乎已成为了每个开发人员的固有意识，甚至不必思考便可脱口而出一些常用的分层架构，这其中最为经典的就是三层架构，即使没有学习过 DDD 的同学也耳熟能详。
经典三层架构从上往下分别是用户界面层，业务逻辑层和数据访问层：
用户界面层面向用户的体验与交互
业务逻辑层面向应用与业务逻辑
数据访问层面向各种外部资源与设备
这种分层架构属于严格分层架构，即某层只能与位于其直接下方的层发生耦合，它有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化。
DDD 四层架构
学习过 DDD 的同学，肯定听说过 DDD 四层架构，它有效的分离了业务复杂度与技术复杂度，凸显了领域模型。
DDD 四层架构从上往下分别是用户界面层，应用层，领域层和基础设施层：
User Interface 为用户界面层(或表示层)，负责向用户显示信息和解释用户命令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人
Application 为应用层，定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其它系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作，使它们互相协作。它没有反映业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度
Domain 为领域层(或模型层)，负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心，领域模型位于这一层
Infrastructure 层为基础实施层，向其他层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件，等等。基础设施层还能够通过架构框架来支持四个层次间的交互模式
这种分层架构属于松散分层架构，即某层可以与它的任意下方层发生耦合，而经典三层架构属于严格分层架构。
DDD 四层架构在经典三层架构的基础上做了一些改良：
在用户界面层与业务逻辑层之间引入了新的一层，即应用层
将业务逻辑层更名为领域层，更加的贴合了语义
将数据访问层更名为基础设施层，则突破了之前数据库管理系统的限制，扩大了这个负责封装技术复杂度的基础层次的内涵
DDD 分层架构经验
在经典三层架构和 DDD 四层架构的基础上，我们在实践中不断改进，总结出了三种 DDD 分层架构的模式：
