传统的三层架构
简介
各层之间采用接口相互访问，并通过对象模型的实体类(Model)作为数据传递的载体，不同的对象模型的实体类一般对应于数据库的不同表，实体类的属性与数据库表的字段名一致。
职责划分
| 层 | 描述 |
|---|---|
| User Interface layer(表示层, UI) | 接受对用户的请求并返回数据，将结果呈现给用户。 |
| Business Logic Layer(业务逻辑层, BLL) | 主要负责接受表现层的请求，进行各种业务逻辑运算，然后通过数据访问层完成数据的操作。 |
| Data Access Layer(数据访问层, DAL) | 主要负责数据的查询、持久化等操作，关注数据一致性、准确性，不关注业务逻辑 |
从上面的职责划分可以看出，此架构模型符合“高内聚，低耦合”思想；其特点是以数据库为起点进行系统分析和设计。
包结构
典型的目录结构划分：
- com.xxx.project
- service(biz、manager) ：各种业务逻辑放在此包中实现
- view：负责视图层
- dao：负责db的数据访问
分布式架构
DDD分层架构
简介
DDD的核心是领域层。每层只能与其下方的层产生依赖。
注：图中在「四层架构」的基础上演进行成了「依赖倒置的四层架构」，各层通过仓储接口来方位基础层。
职责划分
User Interface(用户接口层)
职责：
负责向用户显示信息、解释用户命令。这里的用户可以是真正的用户、自动化测试程序、批处理脚本等。
主要包括：
外观接口(facade)：用于封装应用服务，完成不同前端的数据适配。
转换器(assembler)：用于将领域对象转换成VO对象。
示例：
PC端要显示订单的完整信息，但是App端仅需要显示少量核心数据；对内应用的数据返回相对完整，但是对外提供Api是仅返回指定的几个字段。这些场景中接口的核心逻辑都一样，只是因为渠道的不同，需要对不同渠道做不同适配，这些都应该在用户接口层完成。
Application Layer(应用层)
主要负责：
协调领域层多个领域服务，面向业务流程完成服务的组合与编排。应用层的服务被用户接口层Facade服务封装，完成接口和数据适配，通过Api网关对前端应用提供服务。
主要包括：
应用服务、领域事件订阅与发布、安全认证、权限校验、事务控制、对其他微服务调用、等等。
事件(event)：用于封装领域事件的订阅预发布。
应用服务(service)：负责对领域服务、其他应用服务的封装、编排、组合。
主要特点：
这一层都很薄，主要是服务的组合与编排。
特别注意：
不要将领域层的逻辑放在应用层中实现，否则很容易导致应用层、领域层的边界混乱，最终导致DDD的四层架构变成三层架构。
Domain Layer(领域层)
主要职能：
实现领域对象或者聚合自身的原子业务逻辑，关注领域模型的能力，不太关注外部用户操作或者流程方面的控制。
主要包括：
领域服务、值对象、实体、聚合、聚合根等。
实体(entity)：用于存放聚合根、实体、值对象等。
事件(event)：用于封装领域事件处理的核心逻辑。
领域服务(service)：用于存放领域服务、工厂类等代码。
仓储(repository)：用于存放仓储服务的代码，隔离领域逻辑和数据存储。
领域服务：
组合、协调聚合内的多个实体或值对象，实现复杂的业务逻辑。
Infrastructure Layer(基础设施层)
主要职能：
为其他各层提供通用的技术和技术服务。
主要包括：
封装消息中间件、网关、缓存、文件服务、数据库等。
主要作用
封装基础资源的服务，实现应用层、领域层、基础层解耦，降低对外部资源依赖。例如：如果没有此层，当消息中间件、缓存变化时，将会大面积修改业务逻辑。