1. 用户界面层（或表示层）
负责向用户显示信息和解释用户指令。这里的用户可以是另一个计算机系统，不一定是使用用户界面的人
2. 应用层
定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道
应用层要尽量简单，不包含业务规则或者知识，而只是为下一层种的领域对象协调任务，分配工作，使它们互相协作。它没有反映业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。
3. 领域层
负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。
4. 基础设施层
为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组建等等。基础设施层还能够通过架构框架来支持4个层次间的交互。
由于应用层负责对领域对象的行为进行协调，因此细粒度的领域对象可能会把领域层的知识泄漏到应用层种。这产生的结果是应用层不得不处理复杂的、细致的交互，从而使得领域层知识蔓延到应用层或用户界面代码当中，而领域层会丢失这些知识。明知的引入领域层服务有助于在应用层和领域层中间保持一条明确的界限。
e.g. 资金转账
应用层 资金转账应用服务
a. 获取输入
b. 发送消息给领域层服务，要求其执行
c. 监听确认消息
d. 决定使用基础设施service来发送通知
领域层 资金转账领域服务
a. 与必要的Account和Ledger(总账)对象进行交互，执行相应的借入和贷出操作
b. 提供结果等到确认
基础设施层 发送通知服务
a. 按照应用程序的指示发送电子邮件、信件和其他信息
领域层的混乱原因
客户需要一种有效的方式来获取对已存在的领域对象的引用，如果基础设施提供了这方面的便利，那么开发人员可能会增加很多可遍历的关联，这会使模型变得非常混乱。另一方面，开发人员可能使用查询从数据库中提取他们所需的数据，或是直接提取具体的对象，而不是通过aggregate的根来得到这些对象，这样就导致领域逻辑进入查询和客户代码中，而entity和value object则变成单纯的数据容器。采用大多数处理数据库访问的技术复杂性很快就会使客户代码变得混乱，这将导致开发人员简化领域层，最终使模型变得无关紧要。
