系统架构之六边形架构介绍

在后端架构演进中传统的传统的三层架构Controller-Service-Repository在项目初期通常能维持清晰的结构。随着业务迭代会出现两类典型问题。其一是业务逻辑外溢。参数校验、权限判断、流程编排散落在Controller与Service中领域规则不再集中同一业务在不同入口Web、定时任务、消息下出现不一致的实现。其二是技术实现渗透。Service直接依赖ORM的Session、注解或事务API导致更换持久化方案时需要修改业务代码。这两个问题的共同根源是高层模块业务逻辑在编译期依赖低层模块数据库、Web 框架。为了解决「业务与技术绑定」的问题六边形架构Hexagonal Architecture应运而生也叫端口与适配器模式Ports Adapters。1、六边形架构是什么六边形架构由Alistair Cockburn在2005年提出其核心思想只有一句话将系统的核心业务逻辑与所有外部依赖完全隔离通过「端口」定义交互契约通过「适配器」完成技术实现。之所以称为「六边形」并不是说系统必须分成6个部分而是用六边形这个几何形状象征系统可以从任意方向接入外部组件没有传统分层架构那种「从上到下」的固定依赖方向。Cockburn最初绘制示意图时使用了六条边以便放置不同的交互方图形的边数不影响架构语义更准确的名称是“端口与适配器”。下图展示了六边形架构的完整结构。在依赖方向上所有依赖都指向内部领域核心。1领域模型位于六边形中心包含实体、值对象、领域服务与业务规则。该层不引入任何框架依赖不包含注解不引用ORM或HTTP库。其可测试性不依赖运行环境。2端口端口是领域层定义的接口描述应用与外界的交互契约。按调用方向分为两类。输入端口/驱动端Driving Port / Inbound Port声明应用能提供的能力例如 「创建订单」的接口。由外部调用方使用接口签名使用领域概念与命令对象。输出端口/被驱动端Driven Port / Outbound Port声明应用需要的资源例如 「保存订单数据」的接口。由领域层调用外部负责实现。端口接口中不应出现HTTP请求对象、数据库连接、框架注解等基础设施类型。3适配器适配器是端口的实现承担协议转换职责。主适配器驱动适配器将外部请求转换为对驱动端口的调用例如REST Controller、gRPC Service、CLI Command、消息监听器。从适配器被驱动适配器实现被驱动端口将领域层的调用转换为对具体技术的操作例如JPA Repository、Kafka Producer、第三方API客户端。2、六边形架构的特性1业务逻辑与技术实现解耦领域核心仅关注业务规则不用感知持久化实现是MySQL还是PostgreSQL也不用感知调用方采用HTTP还是RPC。技术细节封装于适配器内部更换技术栈时仅需替换适配器实现领域代码无需修改。2领域逻辑单元测试成本低对领域逻辑进行单元测试时无需启动数据库或连接外部服务。仅需为输出端口提供测试替身如内存实现即可完成纯领域逻辑的验证显著降低测试执行成本与复杂度。3多入口接入复用领域核心同一领域核心可同时支持Web、移动端、小程序、开放API、内部RPC、定时任务、CLI等多种入口。各入口仅需实现对应的驱动适配器领域逻辑无需重复实现。4依赖方向明确符合依赖倒置原则所有编译期依赖均指向领域层外层依赖内层内层不依赖外层符合依赖倒置原则DIP。新成员介入时可明确区分领域逻辑与技术实现。5支持信创适配与多环境部署在信创改造、多云部署等需要兼容异构数据库与中间件的场景中六边形架构具有明显优势仅需新增对应技术栈的适配器实现领域核心不受影响。3、与主流架构模式对比六边形架构与主流的分层架构、整洁架构洋葱架构、CQRS架构对比如下所示传统分层架构Layered / MVC通常按技术职责划分为Controller、Service、DAO/Repository与Database等层次调用关系自上而下Service层直接依赖持久化实现因此更换数据库或ORM往往需要调整业务代码业务逻辑容易与技术细节耦合单元测试也因依赖外部资源而成本较高其优势是结构直观、上手成本低适合业务规则简单且技术栈相对稳定的CRUD系统。六边形架构Ports Adapters以领域核心为中心通过入端口与出端口分别声明应用能力和外部资源需求REST、MQ、MySQL、Redis等具体技术均由适配器实现编译期依赖统一指向中心领域核心只保留纯业务逻辑不感知上层协议与底层存储选型因而具备业务纯粹、易测试、适配器可插拔等特征适用于领域逻辑复杂、需要多入口复用或存在基础设施替换需求的系统。整洁架构Clean Architecture / 洋葱架构采用同心圆层次结构由内到外依次为实体、用例、接口适配器以及框架与驱动器依赖规则要求由外向内内层稳定且抽象外层偏向具体技术实现相比六边形架构它更强调分层与边界约束层次划分更精细、依赖规则更严格适合大型复杂项目但学习曲线与设计成本也更高。CQRSCommand Query Responsibility Segregation将写端与读端彻底分离写端通过 Command、领域模型与事件存储处理状态变更并写入写数据库读端通过 Query、DTO投影直接查询读数据库两端可独立选型、独立扩展便于针对读写负载分别优化性能但会引入最终一致性、投影更新与事件处理等复杂度适用于读写比差异极大、高并发或需要事件驱动与审计能力的系统。四种架构对比如下维度传统分层(MVC)六边形架构整洁架构CQRS提出者通用实践Alistair CockburnRobert C. MartinGreg Young核心理念按职责分层端口与适配器隔离同心圆依赖规则读写分离业务独立性弱强强较强依赖方向自上而下指向中心由外向内独立管道技术替换成本高低低中学习曲线低中较高高最佳搭配简单CRUDDDDDDD事件溯源(ES)注六边形架构和整洁架构本质思想一致依赖倒置业务为核心六边形更偏重端口-适配器的实操模式整洁架构更强调严格的同心圆分层。实际项目中两者经常组合使用4、六边形架构适用场景六边形架构在业务逻辑与技术实现解耦测试可以脱离外部依赖运行替换基础设施的成本降低领域模型的演进不受框架升级影响。相应的端口与适配器引入额外抽象增加代码量与间接层团队需要具备依赖倒置与领域建模能力否则容易出现“目录结构符合、依赖方向错误”的情况对于领域逻辑简单、基础设施稳定的系统这些抽象不产生实际收益。因此六边形架构适用于领域逻辑复杂且需要长期维护存在替换数据库、消息中间件或外部服务的现实需求核心业务逻辑需要高覆盖率的自动化测试同一套业务逻辑需要被多种入口Web、消息、批处理复用。Cockburn提出这一模式的原始动机是解决业务逻辑渗透进UI代码、系统绑定特定数据库导致测试困难的问题。不过这两个问题在当前的中大型系统中依然普遍存在。参考资料The Hexagonal (Ports Adapters) ArchitectureAlistair Cockburn 2005https://blog.csdn.net/luo15242208310/article/details/124708008Layered/Hexagonal/Clean/Onion架构横向对比