一、背景介绍

在集团PaaS化战略引导下，笔者负责的闪电敏捷团队在近半年完成了京东快退的解约和撤销2个子系统的B-PaaS架构升级，在此基础上，快退还完成配置化系统升级，无论业务支持、产品沟通和系统交付能力都实现了跨越式的突破。

1.业务上的支持，以集团长城融合项目为始，通过PaaS化升级改造，在原有整单退业务上支持了订单的SKU调整退业务，如不做PaaS化架构升级则需要重新构建调整退款系统支持；B商城项目中B和C端能力融合，与订单中台侧团队合力在C端订单原有状态的节点上进行能力复用，完美融合了B商城的意向单逆向业务。在未来，还将扩展支持更多集团战略项目。

2.产品上的支持，以集团复杂业务为底，快退平台承接了集团零售几乎所有售前逆向拦截和退款业务，业务复杂度极高，产品和研发日常只能以模块到人的方式沟通，比如以商详结算页为例Handler业务处理器185，而快退侧Handler业务处理器189不包含拦截器Interceptor，通过梳理合并相似业务流程，通用流程65+。通过PaaS化架构升级，不仅对业务建模、流程可视化，同时构建领域模型，沉淀一套核心业务流程，从产品沟通需求3人日降低至0.5H。

3.系统上的支持，集团在过去几年不仅扩充了主站业务，同时进行了出海战略（比如泰国站、印尼站的国际化业务）、商业战略（比如北汽、商羚、千帆等商业化业务）的投入，构建了多个烟囱重复系统，不仅在业务上很多能力相似，还增加了研发维护和投入成本。通过PaaS化架构升级，目前已将农批业务进行PaaS化架构支持，其他业务也在进行PaaS一套内核支持，多个垂直业务分包的融合。维护人员从原来6人投入，目前只需要3人（包含2名2022年应届生）。

二、产品介绍

2.1、快退是什么？

2.1.1、快退在C端用户消费者眼里是什么？

2.1.2、快退其他视角下是什么？

C端:面向C端用户完成支付前取消、支付完成后取消

商家:面向POP商家完成协助用户代取消，面向门店商家

运营:面向自营产品，同POP商家代取消

客服:面向财务审核异常，以及用户进线投诉取消

拒收:面向配送产品到顾客，联系不上或者用户拒收

天网:面向黑名单用户，套利或者逃运费的风控拦截

2.1.3、快退是什么？

我们用一句话总结：快退平台是面向消费者、商家、风控、客服等多种角色， 提供实物或者虚拟退款的解决方案，致力于打造售前解约方案一体化平台。

三、领域建模

3.1、建模的价值和必要性

在建模前，我们来看一张图，该图主要讲解了领域专家、项目经理、架构师、产研团队等人如何进行协作，也是讲述了建模的过程和必要性，尤其是统一语言、更好的还原业务真实度场景。

我们从中提取下关键词：问题域、业务期望，业务流程图、场景活动分析，业务边界、团队组织产品边界以及技术实现的系统架构边界。我用一句话归纳下，我们是在特定的业务场景下，明确该业务场景下的问题域，通过元素和关系来表述出业务规则，进行当前问题的解决方案输出。

3.2、建模前工作准备

3.2.1、明确目标

从宏观目标来说：企业架构(Enterprise Architecture)始于 20 世纪 60 年代，截至目前已有接近六十年的发展历程， 也诞生很多成熟的企业架构与方法，例如Zachman、TOGAF、DoDAF 等， 这些企业架构框架被应用于各类企业和组织的顶层设计 。那么通过对于企业架构的规划和设计，可以帮助企业构建整体的数字化策略，规划数字化项目，通过数字化的手段帮助其实现期望的战略目标和业务结果， 形成企业的数字化顶层规划与设计，指导企业的数字化转型过程。

为了构建现代化企业架构，打破数据孤岛，消灭烟囱重复建设，利用PaaS化的方式落地业务中台架构，助力企业的数字化转型。我们需要将现有业务系统进行业务流程梳理，识别差异化点，构建一套业务流程共享的内核，多个垂直化业务流程的扩展能力支持。

从微观目标来说：业务系统在人员交替，资料不全，代码堆砌，业务野蛮扩张的过程中，不断加深了软件复杂度的治理难度，从产品讲不全业务背景，沟通不全产品能力，研发对于业务逻辑不敢修改，上线频繁出现业务场景缺失验证等问题。不仅加剧了产研交付周期，从需求吞吐量来说也逐步下降，只留下产研团队在艰难的维护，制约了创新产品和业务的发展。

为了提升产研交付效率，降低交付周期，提升需求吞吐量，更好的支持为了产品的创新和业务创新发展，那么是时候进行产品系统的精简瘦身。

3.2.2、看清现状

3.2.2.1、从业务需求分析：大家如果有固定的业务运营团队，这里可以依据业务运营团队进行业务需求分析归纳和整理，以及未来的展望。如果没有业务运营团队，比如是基础能力部门，往往对接的业务方非常多，这里面就面临一个困境，我们没法与业务沟通，则这里我们可以进行以往业务需求分析，比如笔者要讲的这个案例，从以往需求中进行归类，分为需求重灾区和轻灾区。

3.2.2.2、从问题空间分析：1、业务问题：业务方多，业务需求不集中；2、产品问题：产品对于业务需求把控弱，产品边界模糊，行业缺少成熟方案，产研认知不统一；3、系统问题：业务模式乱，依赖上下游多，业务流程复杂不易阐述清晰。

3.2.3、寻求解法

从上面我们能看到，如果只是从业务建模其实无法避免上述所有的问题，业务-组织-技术-运营之间关系互相依赖。那么我们需要从两个方面解决，一个是组织机制流程方面，我们把它归纳为需求和产品管理；另外一个是系统业务复杂度的治理，我们把它归纳为系统管理。

3.2.3.1、需求和产品管理

从痛点入手，进行产研交付需求流程分析，进行解法归纳，落地工具保障需求的规范合理性执行。

3.2.3.2、系统管理

以上我们已经将需求和产品的问题进行规范化管理，那么对于系统层面的问题和痛点我们要怎么做呢？这里面就进入了我们建模能解决的问题，只针对系统层面如何让系统更好的支持业务。

3.3、建模面临的挑战

系统的挑战：系统足够复杂，接近6年的堆砌代码老应用，集团战略需求的重灾区。组织的挑战：团队新组建，新的产研团队，资料老旧且不全。没有头脑风暴的业产研沟通，还需要进行需求的日常交付。9个字表达就是抓重点，搞突破，扩全面。

3.4、如何建模

以现代化企业架构思想为指导，构建业务架构元模型，进行业务、运营、组织和技术的整合，通过流程建模、领域建模、业务身份建模、能力建模进行业务架构的落地。

3.4.1、流程建模

从业务运营规则入手，进行流程梳理，将业务逻辑和领域逻辑剥离开，以下图是我们举个例子，从用户取消订单到最后发起退款。

那么我们在梳理运营规则的时候，其实已经是将业务流程还原的第一步，但是这个时候我们如何划清业务边界呢？我们可以通过接口契约进行隔离。大家再来看这个图是不是清晰多了，而业务逻辑和领域逻辑也进行了分离。

那么我们从上面流程来看其实我们发现我们会有以订单为主的申请、生产单为主的商家/仓储、运单为主的配送、审核单的客服、账单的退款。所以我们可以简化下本模型，本模型只分为4个逻辑模块，分别是解约申请、解约拦截（商家审核/仓储拦截/配送拦截）、解约审核（客服审核/财务审核）、解约生效（财务退款），这样我们的模型就抽象的比较简单了。

3.4.2、领域建模

构建一个解约单领域模型，来描述下我们通常看到的”鸡蛋”。我们将业务领域划分，划分为5个领域，除解约单外，就是我们上述流程建模中的四个核心子域，申请域、解约域、审核域、生效域。领域对象分为解约申请单、解约拦截单、解约审核单、解约生效单。

接下来我们进行统一业务语言，领域事件活动分析，进行领域服务拆解（这里强调的信息内容与DDD的领域服务略有不同，更强调的是偏微观，比如RPC接口纬度）。

接下来进行领域事件活动分析，并进行领域服务拆解，沉淀我们的领域服务、领域能力、以及不同垂直业务的差异点进行扩展点抽离

在藏经阁-尊敬哥的可扩展性架构中其实有提到这块内容，如下图，通过借鉴优秀的nginx、asp.net 生命周期管理进行的业务流程设计，与我上述的方式比较相似。

3.4.3、业务身份与数据建模

基于藏经阁的业务身份进行拆解定义,业务身份是针对不同业务方的唯一标识，分辨各个业务系统，业务身份分为垂直业务身份和水平业务身份。从业务目标来说：通过业务身份对不同的业务方需求进行业务逻辑隔离，中台以业务身份为主线赋能不同的业务方的各种定制化场景。从技术目标来看：系统运行期定位扩展点的核心依据，每个扩展点的实现与业务身份直接绑定。

明确垂直业务身份定义：能够独立提供商品或者服务，不依赖其他业务条线独立展开经营活动，称之为垂直业务。比如京东健康、消费品事业部、7Fresh、京东国际化、泰国站、印尼站等。

明确水平业务定义：不能够独立提供商品或服务，必须依赖其他业务所包含的商品或服务，并且需要结合其他业务规则才能完成完整的经营活动。如秒杀、拼购等。水平业务是未来结构化表达中台沉淀的业务资产的方式。

明确场景定义：场景是垂直业务身份下更细粒度的业务逻辑隔离标识，在业务逻辑差异较少（技术层面上即扩展点有不同实现的数量较少）的情况下，可以使用场景做逻辑隔离，它的使用方式相比垂直业务更加轻量。

垂直业务和水平业务之间业务规则是可以叠加的，发生业务规则冲突时，需要判断业务优先级。而多个垂直业务之间的业务规则是不可以叠加的。一个业务完整规则由一个垂直业务规则+N个水平业务规则叠加而成。

业务身份我们定义好以后，我们进行数据模型映射，比如我们这里举个例子，7鲜业务身份，自营业务身份来进行数据建模，通过垂直、水平、内核来定义。

3.5、模型的验证

在我们建模以后，很多用户比较苦恼的是我们的模型是否与我们的业务相吻合？再言之，是不是我们的模型1:1的还原了真实的业务活动场景，那么这个模型的验证或者推演其实是构建模型的核心。

那么无独有偶，在快退中，由于我扮演多个角色、团队负责人，架构师，还得承担一线研发的需求评估，所以总结出一套基于消息消息驱动的模型架构，还原了真实业务场景并指导了研发的落地。

四、B-PaaS化落地实践

4.1、B-PaaS化工程架构指导

以PaaS化工程架构为基础进行系统架构的升级改造

比如我们落地工程架构如下：

4.2、实际需求案例落地PaaS化

4.2.1、业务流程分析

通过以B商城业务和C商城业务融合单据为点，我们进行流程分析，分析图如下，识别业务域、通用流程和可变点设计，从而辅助我们构建内核和扩展点的业务逻辑抽离。

4.2.2、业务领域活动分析

领域事件拆解，识别领域对象、以及对应的业务子域，辅助研发进行业务和领域逻辑剥离。

基于领域进行消息驱动开发，落地工程结构代码映射，并通过核心域进行流程编排。

4.2.3、业务身份识别

通过藏经阁注册的业务身份进行映射，找到对应本地的系统业务身份解析要素，进行业务ID的识别

五、能力可视化

在第四小节中，我们进行了B-PaaS化工程落地实践，最终借助藏经阁进行能力可视化上报，笔者项目是通过注解的方式进行上报。

以上是京东快退(订单逆向履约)系统的建模与PaaS化落地实践分享，后续会进行JDD内容分享，敬请期待！