协议驱动（一）

协议驱动协议驱动设计围绕三大核心原则落地适配轻量化、高迭代的开发场景。三大核心思想具体如下接口即协议独立闭环每一个API接口对应一套独立协议各协议拥有专属的入参模型、出参模型、业务处理类业务逻辑完全闭环。协议扁平对等无相互依赖所有协议处于同一层级、地位平等无上下级、无优先级区分禁止协议之间相互调用、耦合依赖。协议用完即弃迭代换新协议适配当前业务场景即可一旦出现场景不适配、大规模不兼容迭代不改造旧协议直接全新创建协议旧协议保留、按需废弃。极度适配中小团队敏捷迭代实现主动拥抱需求变化、核心业务保持恒定无需复杂 DDD 领域建模、无需高强度代码评审适配工期紧、需求多变、无详细前置设计的开发场景用轻量化架构解决传统分层架构职责混乱、代码失控的顽疾。哪里有敏捷开发只不过是把工期紧任务重并且没有详细设计加上边做边想甚至是先做出来再说这种开发流程美化一番好让程序猿同学有种非常高大上的错觉从而心甘情愿地多加班而已业务背景在遥远的sevlet年代一个sevlet将业务逻辑处理、数据持久化包干。后来拆分成‘模型 - 视图 - 控制器’三层又添加并细分‘Controller - Service - Dao’Controller负责请求接收、参数校验、路由调度与响应返回Service专注核心业务逻辑的编排与实现Dao负责数据库交互、数据持久化操作。这套分层架构虽实现了基础职责拆分但在中小团队、高频迭代的业务场景中暴露了无法规避的短板Service层代码臃肿膨胀随着业务迭代迭代大量业务逻辑堆砌在Service类中多人协作开发时极易出现代码冲突、分支合并问题文件体量持续失控。层级边界混乱隔离失效受开发人员能力、规范落地不到位影响层级职责经常被打破部分开发者会将业务逻辑写入Controller层甚至直接在控制层通过Dao、JDBC操作数据库即便项目已定义标准化入参模型仍存在通过request.getParameter()手动获取参数的不规范操作。架构适配性有限大厂可通过领域驱动设计DDD、严格代码评审、规范化研发流程保障代码质量、延长代码生命周期。但绝大多数小微企业无专职代码审核人员研发人员能力参差不齐传统分层架构的规范难以落地代码冗余、耦合、混乱问题愈发严重维护成本极高。协议驱动设计正是针对中小团队快速迭代、规范薄弱、业务多变的场景提出的轻量化破局方案。协议驱动核心思想深度解析1. 最小颗粒度协议拆分业务完全闭环协议对应的API接口需拆分至最小业务颗粒以业务场景、功能单一为拆分依据即便同为Banner图查询接口若A、B两处返回数据格式不同需拆分为两个独立协议新增、编辑类操作若业务逻辑、数据校验规则不同可独立拆分协议坚决杜绝“大一统接口”禁止一个接口承载页面全部数据返回、多场景复合业务处理。同时每个协议的入参模型、出参模型、业务处理类专属独享仅服务于当前协议业务物理层面将臃肿的Service大类按单一业务维度拆分为多个独立协议处理类从根源解决代码膨胀问题单一协议的代码修改、迭代、Bug修复完全不会影响其他协议实现业务逻辑物理隔离问题定位精准高效所有与某一接口相关的问题仅局限于对应协议的代码范围内大幅降低排查成本。协议扁平解耦无状态无依赖所有协议保持扁平、对等、无状态特性不存在层级关系、优先级差异和相互依赖调用。该设计的核心目的是极致解耦、强化单一职责即使删除某一个协议的全部代码也不会对系统内其他协议、其他业务逻辑造成任何影响彻底规避跨业务耦合风险。用完即弃契合开闭原则当业务出现大规模迭代新旧接口逻辑不兼容、无法通过简单兼容改造适配时无需修改旧协议代码直接全新开发一套新协议即可。新旧协议并行存在、各司其职完美契合软件设计的开闭原则对修改关闭、对扩展开放。客户端未升级场景持续调用旧协议保留原有业务逻辑客户端已升级场景切换调用新协议执行全新业务逻辑。坚决杜绝在同一个接口中堆砌大量版本兼容代码避免代码冗余、逻辑混乱。仅需特殊校验是否存在“客户端未升级但必须使用新协议”的特殊场景评估场景合理性与落地必要性即可。代码复用与数据持久化落地方案协议扁平独立、互不调用的设计可规避耦合问题但也衍生出核心问题多协议存在公共逻辑、重复代码以及统一数据持久化如何处理核心解决方案为逻辑下沉、分层复用。协议驱动不强制限定 Model、Service、Dao 的固定架构可与行业主流的数据驱动模式混用一张数据库表对应一套独立的表模型Model、Dao操作类、Mapper映射文件、通用Service类。其中表对应通用Service类主要承担两大核心职责实现代码复用与能力下沉通用数据操作封装封装单表/关联子表的通用增删改查能力包含分页查询、新增、修改等基础数据库操作与具体业务场景解耦核心公共业务封装沉淀多协议通用的核心业务逻辑如缓存管理、发送消息等避免重复编码。通过该方式协议处理类仅专注于自身专属业务逻辑通用数据库操作、公共逻辑全部下沉至基础Service层既保留协议的独立性又解决了代码复用问题。灵活适配原则规范服务于业务协议驱动的核心目标是简化开发、降低维护成本而非固化刻板规则。若少量多个协议存在完全一致的入参、出参模型且业务处理逻辑高度重合允许直接复用模型与核心代码无需强行拆分冗余代码。所有架构规范均为业务服务在不破坏核心解耦、独立闭环的前提下可根据实际场景灵活适配兼顾架构规范性与开发高效性。对应实战项目地址https://github.com/bugCats/cat-bcdt包括网址导航SQL版本管理SQL计划任务Mysql代理数据库账号权限申请审批代码生成web端日志查阅团队日报禅道、Jenkins、Gitea、Gitlab消息集成等案例分析案例1最小颗粒协议拆分对应独立闭环思想商城首页需要展示两种Banner广告首页轮播Banner、弹窗推荐Banner。二者数据库字段一致但前端渲染出参格式不同轮播Banner需返回图片地址、跳转链接、排序权重弹窗Banner仅需返回图片地址、展示时长。传统写法容易合并为一个 getBanner() 大一统接口冗余字段多、迭代牵一发而动全身。协议驱动模式下直接拆分为 BannerHomeProtocol、BannerPopupProtocol 两个独立协议各自配备专属入参、出参和处理类后续仅修改弹窗Banner逻辑时完全不会影响首页轮播业务。案例2协议扁平无依赖对应对等解耦思想用户中心包含「用户登录」「用户信息查询」「用户手机号修改」三个接口对应三套独立协议。传统Service架构下三类用户业务逻辑会堆砌在同一个UserService中修改手机号逻辑极易误影响登录、查询功能多人开发也容易产生代码冲突。而协议驱动模式下三个业务对应三个扁平独立协议互不依赖、互不调用。物理删除用户手机号修改协议的全部代码登录、用户查询功能完全不受影响真正实现协议之间彻底解耦、零耦合风险。案例3协议用完即弃、版本迭代换新对应开闭原则思想商城订单接口迭代场景V1版本订单接口仅支持普通实物订单下单逻辑简单、参数较少后续业务升级新增预售订单、分期支付订单且新增大量校验字段、履约逻辑新旧逻辑完全不兼容。传统开发写法在原有订单接口中新增大量if/else兼容判断堆砌V1、V2两套逻辑代码臃肿晦涩后续迭代极易出Bug维护难度极大。协议驱动写法不改动原有V1订单协议代码全新开发一套V2订单协议。老版本APP调用旧协议保持原有下单逻辑稳定新版本APP调用新协议适配全新订单业务。无需兼容旧逻辑、不污染老代码完美实现用完即扔、迭代扩展。案例4公共逻辑下沉复用对应分层落地方案系统中「商品列表查询」「商品详情查询」两个独立协议均需要查询商品基础数据、统一封装商品状态、过滤下架商品。按照协议规范两个协议代码独立、不能相互调用。此时将商品基础查询、状态过滤通用逻辑下沉至商品基础Service层两个协议分别调用Service公共能力自身仅保留各自专属业务逻辑列表协议专注分页、排序、精简字段返回详情协议专注参数校验、完整数据组装。既保证协议独立解耦又避免大量重复代码。案例5规范灵活适配、避免过度设计对应灵活适配原则系统内「获取用户基础信息」「获取用户实名认证信息」两个简单接口入参均为用户ID、出参均为基础用户字段无特殊差异化逻辑。无需强行拆分两套模型、两套处理类可直接复用同一套出入参模型和公共处理逻辑。 协议驱动核心是解耦、提效而非机械刻板拆分在不破坏核心架构思想的前提下可灵活复用代码规避过度设计。