一、概述
DDD主要用来从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。今天我们主要聊下DDD分层架构与代码模型这部分。
二、分层架构
三层架构和四层架构对比如下：
三层架构模型分为接口层，逻辑层，数据访问层，三层架构更简洁，适合快速开发迭代。
DDD四层架构分为用户接口层，应用层，领域层，基础层。
Interfaces（用户接口层）：它主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求，解析用户输入的配置文件，并将数据传递给 Application 层。数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。
Application（应用层）：它主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。
Domain（领域层）：它主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。
Infrastructure（基础层）：它主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。
架构根据耦合的紧密程度可以分为两种：严格分层架构和松散分层架构。严格分层架构，任何层只能对位于其直接下方的层产生依赖。松散分层架构，它允许某层与其任意下方的层发生依赖。
在严格分层架构中，领域服务只能被应用服务调用，应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰。
在松散分层架构中，领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理。
三、代码模型
代码模型如下，每层目录职责见图中说明：
