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和微服务》

Logo

开源、云原生的融合云平台

更多推荐