导读
本文重点介绍了京东零售电商业务在订单逆向履约上面的最佳技术实践，京东零售快退平台承接了零售几乎所有售前逆向拦截和退款业务，并在长期的业务和技术探索中沉淀了丰富的业务场景设计方案、架构设计经验，既能承接面向消费者 C 端用户的高并发流量，同时也能满足集团复杂业务的订单信息流、货品实物流、财务资金流的逆向精准拦截。本文通过对集团 B-PaaS 化技术方案进行系统整体的架构升级改造，总结归纳出涵盖用户解约流程管理、撤销解约流程管理、订单逆向退款信息管理、流程配置化和流程可视化一整套的解决方案，该方案经过多次探讨和验证，已支持集团多个战略业务的增长。阅读本文，读者可以了解到整个快退平台新系统设计的底层逻辑，也可以参考本文并结合实际场景，将方案应用在遗留债务系统改造、业务和技术建模中。
一、背景介绍
在集团 PaaS 化战略引导下，笔者负责的闪电敏捷团队在近半年完成了快退系统的解约和撤销 2 个子系统的 B-PaaS 架构升级，在此基础上，快退还完成配置化系统升级，无论业务支持、产品沟通和系统交付能力都实现了跨越式的突破。
1. 业务上的支持，以集团长城融合项目为始，通过 PaaS 化升级改造，在原有整单退业务上支持了订单的 SKU 调整退业务，如不做 PaaS 化架构升级则需要重新构建调整退款系统支持；B 商城项目中 B 和 C 端能力融合，与订单中台侧团队合力在 C 端订单原有状态的节点上进行能力复用，完美融合了 B 商城的意向单逆向业务。在未来，还将扩展支持更多集团战略项目。
2.产品上的支持，以集团复杂业务为底，快退平台承接了集团零售几乎所有售前逆向拦截和退款业务，业务复杂度极高，产品和研发日常只能以模块到人的方式沟通，比如以商详结算页为例 Handler 业务处理器 185，而快退侧 Handler 业务处理器 189 不包含拦截器 Interceptor，通过梳理合并相似业务流程，通用流程 65+。通过 PaaS 化架构升级，不仅对业务建模、流程可视化，同时构建领域模型，沉淀一套核心业务流程，产品沟通的人员需求降低了 83%。
3. 系统上的支持，集团在过去几年不仅扩充了主站业务，同时进行了出海战略、商业战略的投入，构建了多个烟囱重复系统，不仅在业务上很多能力相似，还增加了研发维护和投入成本。通过 PaaS 化架构升级，目前已将农批业务进行 PaaS 化架构支持，其他业务也在进行 PaaS 一套内核支持，多个垂直业务分包的融合。维护人员投入减少了一半。
二、产品介绍
2.1 快退是什么？
2.1.1 快退在 C 端用户消费者眼里是什么？
图 1 C 端用户视角下的快退
2.1.2 快退其他视角下是什么？
C 端：面向 C 端用户完成支付前取消、支付完成后取消
商家：面向 POP 商家完成协助用户代取消，面向门店商家
运营：面向自营产品，同 POP 商家代取消
客服：面向财务审核异常，以及用户进线投诉取消
拒收：面向配送产品到顾客，联系不上或者用户拒收
天网：面向黑名单用户，套利或者逃运费的风控拦截
2.1.3 快退是什么？
用一句话总结：快退平台是面向消费者、商家、风控、客服等多种角色， 提供实物或者虚拟退款的解决方案，致力于打造售前解约方案一体化平台。
三、领域建模
3.1 建模的价值和必要性
在建模前首先来看下图，该图主要讲解了领域专家、项目经理、架构师、产研团队等人如何进行协作，也是讲述了建模的过程和必要性，尤其是统一语言、更好的还原业务真实度场景。
图 2 建模的过程和必要性
可以从中提取下关键词：问题域、业务期望，业务流程图、场景活动分析，业务边界、团队组织产品边界以及技术实现的系统架构边界。用一句话归纳下，在特定的业务场景下，明确该业务场景下的问题域，通过元素和关系来表述出业务规则，进行当前问题的解决方案输出。
3.2 建模前的工作准备
3.2.1 明确目标
从宏观目标来说：企业架构 (Enterprise Architecture) 始于 20 世纪 60 年代，截至目前已有接近六十年的发展历程，也诞生很多成熟的企业架构与方法，例如 Zachman、TOGAF、DoDAF 等，这些企业架构框架被应用于各类企业和组织的顶层设计 。那么通过对于企业架构的规划和设计，可以帮助企业构建整体的数字化策略，规划数字化项目，通过数字化的手段帮助其实现期望的战略目标和业务结果， 形成企业的数字化顶层规划与设计，指导企业的数字化转型过程。
为了构建现代化企业架构，打破数据孤岛，消灭烟囱重复建设，利用 PaaS 化的方式落地业务中台架构，助力企业的数字化转型，需要将现有业务系统进行业务流程梳理，识别差异化点，构建一套业务流程共享的内核，多个垂直化业务流程的扩展能力支持。
从微观目标来说：业务系统在人员交替，资料不全，代码堆砌，业务野蛮扩张的过程中，不断加深了软件复杂度的治理难度，从产品讲不全业务背景，沟通不全产品能力，研发对于业务逻辑不敢修改，上线频繁出现业务场景缺失验证等问题。不仅加剧了产研交付周期，从需求吞吐量来说也逐步下降，只留下产研团队在艰难的维护，制约了创新产品和业务的发展。
为了提升产研交付效率，降低交付周期，提升需求吞吐量，更好的支持为了产品的创新和业务创新发展，那么就需要进行产品系统的精简瘦身。
3.2.2 看清现状
1. 从业务需求分析：如果读者有固定的业务运营团队，这里可以依据业务运营团队进行业务需求分析归纳和整理，以及未来的展望。如果没有业务运营团队，比如是基础能力部门，往往对接的业务方非常多，这里面就面临一个困境：没法与业务沟通，在这里则可以进行以往业务需求分析，比如笔者要讲的这个案例，从以往需求中进行归类，分为需求重灾区和轻灾区。
图 3 业务需求分析的角度
2. 从问题空间分析：（1）业务问题：业务方多，业务需求不集中；（2）产品问题：产品对于业务需求把控弱，产品边界模糊，行业缺少成熟方案，产研认知不统一；（3）系统问题：业务模式乱，依赖上下游多，业务流程复杂不易阐述清晰。
图 4 问题空间分析的角度
3.2.3 寻求解法
从上面可以看到，如果只是从业务建模其实无法避免上述所有的问题，业务 - 组织 - 技术 - 运营之间关系互相依赖。那么就需要从两个方面解决，一个是组织机制流程方面，可以把它归纳为需求和产品管理；另外一个是系统业务复杂度的治理，则把它归纳为系统管理。
1. 需求和产品管理
从痛点入手，进行产研交付需求流程分析，进行解法归纳，落地工具保障需求的规范合理性执行。
图 5 需求和产品管理
2. 系统管理
以上已将需求和产品的问题进行规范化管理，那么对于系统层面的问题和痛点要怎么做呢？这里面就进入了建模能解决的问题，只针对系统层面如何让系统更好的支持业务。
3.3 建模面临的挑战
系统的挑战：系统足够复杂，接近 6 年的堆砌代码老应用，集团战略需求的重灾区。组织的挑战：团队新组建，新的产研团队，资料老旧且不全。没有头脑风暴的业产研沟通，还需要进行需求的日常交付。9 个字表达就是抓重点，搞突破，扩全面。
图 6 建模面临的挑战
3.4 如何建模
以现代化企业架构思想为指导，构建业务架构元模型，进行业务、运营、组织和技术的整合，通过流程建模、领域建模、业务身份建模、能力建模进行业务架构的落地。
图 7 建模过程
3.4.1 流程建模
从业务运营规则入手，进行流程梳理，将业务逻辑和领域逻辑剥离开，以下图为例，从用户取消订单到最后发起退款。
图 8 流程建模
在梳理运营规则的时候，其实已经是将业务流程还原的第一步，但此时要如何划清业务边界呢？可以通过接口契约进行隔离。再来看下图就清晰许多，而业务逻辑和领域逻辑也进行了分离。
图 9 通过接口契约划清业务边界
从上面的流程来看其实可以发现有以订单为主的申请、生产单为主的商家/仓储、运单为主的配送、审核单的客服、账单的退款。因此可以简化下本模型，本模型只分为 4 个逻辑模块，分别是解约申请、解约拦截（商家审核/仓储拦截/配送拦截）、解约审核（客服审核/财务审核）、解约生效（财务退款），该模型就抽象的比较简单了。
图 10 简化后的模型
3.4.2 领域建模
构建一个解约单领域模型，来描述下通常会看到的"鸡蛋"。首先将业务领域划分为 5 个领域，除解约单外，就是上述流程建模中的四个核心子域，申请域、解约域、审核域、生效域。领域对象分为解约申请单、解约拦截单、解约审核单、解约生效单。
图 11 构建解约单领域模型的 “鸡蛋”
接下来统一业务语言，领域事件活动分析，进行领域服务拆解（这里强调的信息内容与 DDD 的领域服务略有不同，更强调的是偏微观，比如 RPC 接口纬度）。
图 12 通用语言表
接下来进行领域事件活动分析，并进行领域服务拆解，沉淀领域服务、领域能力、以及不同垂直业务的差异点进行扩展点抽离。
图 13 领域事件活动分析
图 14 领域服务拆解
借鉴优秀的 nginx、asp.net 生命周期管理进行的业务流程设计，也与上述的方式比较相似。
图 15 业务流程设计
3.4.3 业务身份与数据建模
业务身份是针对不同业务方的唯一标识，分辨各个业务系统，业务身份分为垂直业务身份和水平业务身份。从业务目标来说：通过业务身份对不同的业务方需求进行业务逻辑隔离，中台以业务身份为主线赋能不同的业务方的各种定制化场景。从技术目标来看：系统运行期定位扩展点的核心依据，每个扩展点的实现与业务身份直接绑定。
明确垂直业务身份定义：能够独立提供商品或者服务，不依赖其他业务条线独立展开经营活动，称之为垂直业务。
明确水平业务定义：不能够独立提供商品或服务，必须依赖其他业务所包含的商品或服务，并且需要结合其他业务规则才能完成完整的经营活动。如秒杀、拼购等。水平业务是未来结构化表达中台沉淀的业务资产的方式。
明确场景定义：场景是垂直业务身份下更细粒度的业务逻辑隔离标识，在业务逻辑差异较少（技术层面上即扩展点有不同实现的数量较少）的情况下，可以使用场景做逻辑隔离，它的使用方式相比垂直业务更加轻量。
垂直业务和水平业务之间业务规则是可以叠加的，发生业务规则冲突时，需要判断业务优先级。而多个垂直业务之间的业务规则是不可以叠加的。一个业务完整规则由一个垂直业务规则 +N 个水平业务规则叠加而成。
图 16 垂直业务和水平业务
业务身份定义好后，进行数据模型映射，举个例子，7 鲜业务身份，自营业务身份来进行数据建模，通过垂直、水平、内核来定义。
图 17 数据模型映射
3.5 模型的验证
建模以后，很多用户比较苦恼的是模型是否与业务相吻合？再言之，模型是不是 1:1 的还原了真实的业务活动场景，那么模型的验证或者推演其实就是构建模型的核心。
无独有偶，在快退中，由于笔者扮演多个角色、团队负责人，架构师，还需承担一线研发的需求评估，因此总结出了一套基于消息消息驱动的模型架构，还原了真实业务场景并指导研发的落地。
图 18 模型的验证
四、B-PaaS 化落地实践
4.1 B-PaaS 化工程架构指导
以 PaaS 化工程架构为基础进行系统架构的升级改造：
图 19 系统架构的升级改造
如落地工程架构如下：
图 20 落地工程架构
4.2 实际需求案例落地 PaaS 化
4.2.1 业务流程分析
通过以 B 商城业务和 C 商城业务融合单据为点进行流程分析，分析图如下，识别业务域、通用流程和可变点设计，从而辅助构建内核和扩展点的业务逻辑抽离。
图 21 业务流程分析图
4.2.2 业务领域活动分析
领域事件拆解，识别领域对象、以及对应的业务子域，辅助研发进行业务和领域逻辑剥离。
图 22 业务领域活动分析图
基于领域进行消息驱动开发，落地工程结构代码映射，并通过核心域进行流程编排。
图 23 消息与领域映射
4.2.3 业务身份识别
通过藏经阁注册的业务身份进行映射，找到对应本地的系统业务身份解析要素，进行业务 ID 的识别。
图 24 业务身份映射
图 25 识别业务 ID
五、能力可视化
上节进行了 B-PaaS 化工程落地实践，最终借助藏经阁进行能力可视化上报，笔者项目是通过注解的方式进行上报。
图 26 能力可视化上报
图 27 上报配置&注解上报能力
六、总结
通过以上背景、产品、建模、工程化、可视化和实际需求落地 B-PaaS 工程的案例 6 个模块，本文整体地介绍了快退平台为什么要进行 PaaS 化工程改造以及具体是如何实现的架构升级。希望通过本文，可以帮助读者们对于订单逆向履约系统有进一步的认识，同时期望给予读者独自面对复杂遗留系统时候，可以借鉴本文的架构升级改造思路，化解业务、系统复杂度，让系统更高效的支持业务发展。此外，也欢迎读者留言探讨交流，是否遇到过复杂的遗留债务系统以及是如何解决的。
作者：京东零售 刘晓成
来源：京东云开发者社区