1 传统的三层架构

1.1 简介

各层之间采用接口相互访问，并通过对象模型的实体类(Model)作为数据传递的载体，不同的对象模型的实体类一般对应于数据库的不同表，实体类的属性与数据库表的字段名一致。

1.2 职责划分

层	描述
User Interface layer(表示层, UI)	接受对用户的请求并返回数据，将结果呈现给用户。
Business Logic Layer(业务逻辑层, BLL)	主要负责接受表现层的请求，进行各种业务逻辑运算，然后通过数据访问层完成数据的操作。
Data Access Layer(数据访问层, DAL)	主要负责数据的查询、持久化等操作，关注数据一致性、准确性，不关注业务逻辑

从上面的职责划分可以看出，此架构模型符合“高内聚，低耦合”思想；其特点是以数据库为起点进行系统分析和设计。

1.3 包结构

典型的目录结构划分：

• com.xxx.project
  • service(biz、manager) ：各种业务逻辑放在此包中实现
  • view：负责视图层
  • dao：负责db的数据访问

2 分布式架构

常见的分布式架构有：DDD分层架构、六边形架构、洋葱架构。

2.1 DDD分层架构

2.1.1 简介

DDD的核心是领域层。每层只能与其下方的层产生依赖。
注：图中在「四层架构」的基础上演进行成了「依赖倒置的四层架构」，各层通过仓储接口来方位基础层。

2.1.2 职责划分

2.1.2.1 项目结构

2.1.2.2 User Interface(用户接口层)

• 职责：
  负责向用户显示信息、解释用户命令。这里的用户可以是真正的用户、自动化测试程序、批处理脚本等。
• 主要包括：
  • 外观接口(facade)：用于封装应用服务，完成不同前端的数据适配。
  • 转换器(assembler)：用于将领域对象转换成VO对象。
• 示例
  PC端要显示订单的完整信息，但是App端仅需要显示少量核心数据；对内应用的数据返回相对完整，但是对外提供Api是仅返回指定的几个字段。这些场景中接口的核心逻辑都一样，只是因为渠道的不同，需要对不同渠道做不同适配，这些都应该在用户接口层完成。

2.1.2.3 Application Layer(应用层)

• 主要负责：
  协调领域层多个领域服务，面向业务流程完成服务的组合与编排。应用层的服务被用户接口层Facade服务封装，完成接口和数据适配，通过Api网关对前端应用提供服务。
• 主要包括：
  应用服务、领域事件订阅与发布、安全认证、权限校验、事务控制、对其他微服务调用、等等。
  • 事件(event)：用于封装领域事件的订阅预发布。
  • 应用服务(service)：负责对领域服务、其他应用服务的封装、编排、组合。
• 主要特点：
  这一层都很薄，主要是服务的组合与编排。
• 特别注意：
  不要将领域层的逻辑放在应用层中实现，否则很容易导致应用层、领域层的边界混乱，最终导致DDD的四层架构变成三层架构。

2.1.2.4 Domain Layer(领域层)

• 主要职能：
  实现领域对象或者聚合自身的原子业务逻辑，关注领域模型的能力，不太关注外部用户操作或者流程方面的控制。
• 主要包括：
  领域服务、值对象、实体、聚合、聚合根等。
  • 实体(entity)：用于存放聚合根、实体、值对象等。
  • 事件(event)：用于封装领域事件处理的核心逻辑。
  • 领域服务(service)：用于存放领域服务、工厂类等代码。
  • 仓储(repository)：用于存放仓储服务的代码，隔离领域逻辑和数据存储。
• 领域服务：
  组合、协调聚合内的多个实体或值对象，实现复杂的业务逻辑。

2.1.2.5 Infrastructure Layer(基础设施层)

• 主要职能：
  为其他各层提供通用的技术和技术服务。
• 主要包括：
  封装消息中间件、网关、缓存、文件服务、数据库等。
• 主要作用
  封装基础资源的服务，实现应用层、领域层、基础层解耦，降低对外部资源依赖。例如：如果没有此层，当消息中间件、缓存变化时，将会大面积修改业务逻辑。

2.1.2.6 架构&职责

2.2 洋葱架构

2.2.1 简介

主要原则：依赖原则，外层依赖内层，内层对外层无感知。
洋葱模型定义了各层的依赖关系，越往里层依赖程度约低，代码级别越高，越是系统的核心能力。

2.2.2 职责划分

• 领域模型：
  实现领域内核心业务逻辑，封装了企业级的业务规则。
  领域模型的主体是实体。
• 领域服务：
  是涉及一个或多个实体的服务业务逻辑。
• 应用服务：
  实现服务组合与编排；
  包含对特定业务流程的封装
• 用户界面&基础资源
  主要提供适配能力，包括主动适配、被动适配。
  主动适配：为外部用户、Web网站等提供对内层业务逻辑的适配；
  被动适配：实现野心业务逻辑对外部资源的访问，例如DB、缓存等。

2.3 六边形架构

2.3.1 简介

注：内六边形(加粗线框内)是核心业务逻辑，他们与外部资源完全隔离，仅通过适配器进行交互。
核心理念：应用是通过端口与外部进行交互的。

2.3.2 职责划分

• 内六边形：
  应用的核心业务逻辑。
• 外六边形：
  完成与外部应用、驱动、基础资源的交互和访问。对前端以主动适配(提供API接口)的形式提供服务；对资源以被动适配的方式进行访问。

2.4 对比

2.4.1 六边形架构 VS 洋葱架构

六边形架构和洋葱架构的设计思路基本相同，都是通过适配器实现业务逻辑与基础设施的接口，避免基础设施代码渗透到业务逻辑中。
洋葱架构在业务逻辑中引入了DDD分层概念，即分为：应用服务、领域服务、领域模型。

2.4.2 DDD分层架构 VS 六边形架构 VS 洋葱架构

虽然模型的表现差异较大，但是他们的核心设计思想都一样：

• 都是做到核心业务逻辑和技术实现细节的分离和解耦。
• 都体现了高内聚，低耦合的设计原则。

3 参考文档

《中台架构与实践-基于DDD和微服务》