合同中心系统的重构历程也见证了车金融业务的发展，作为车金融业务线一个非常重要的系统，从最初的研发繁杂且劳累周期长，到后来了简约配置快速上线业务支持，反映了一个划时代的变化。而我也见证了这个业务系统的成长历程，这背后的架构设计与演进蕴含着设计的扩展性与灵活性，我可以分享给各位看官。
文章目录
零、前言
本文撰写于2020年11月13日至2020年11月22日期间，共计3300余子，内容全部于上下班地铁途中（顺义-大望路）通过手机在有道云笔记编写，后多次修改并润色校稿，并于今日2020年11月22日完成插图。合同重构是业务发展的必然选择，也是其地位的重要性。
一、导读
合同系统作为车金融业务线一个重要的系统，之所以重要在于这些合同从业务上对于意向客户和运营公司具有法律责任特征，因此业务的场景赋予这个系统一个重要的地位，毋庸置疑。
合同伴随着从获客到放款，它伴随着整个业务流程环节。从合同签约的那一刻起，合同系统就会伴随着订单的整个生命周期进行业务就转。
合同包括纸质合同和电子合同，通常一个合同条文的制定以及风险评估会有公司专门负责制定（譬如法务部门）。合同伴随着业务场景的需要，从合同要素根据模板渲染，然后生成电子合同或者纸质合同。
因此合同的管理，包括模板管理，要素配置，逻辑控制，版本控制，不同资方自己业务场景的不同逻辑控制，系统如何设计，如何满足复杂的场景，至关重要。
这篇文章将会介绍重构的历程和背景，以及系统是如何演进的，是如何快速支持业务发展的。同时，又会从架构设计角度来讲，进一步诠释背后的核心设计，对于一些读者将会带来启迪和灵感。
二、入职之初
2017年9月初，我入职了一家公司，属于车金融事业部，我所在的研发团队则是车金融业务线最繁忙而又最重要的核心研发团队。
这个团队支撑整个业务线的需求研发工作，包括APP研发，后端研发，前端研发，测试团队，产品团队，而我属于后端研发的一员。初入职，就是从GPS审核业务模块的需求开始一步步起步的。
最初我们业务线有一个业务系统，就是合同系统，虽然这个系统比较粗糙，但是它具备了模板管理，模板渲染，签章管理等一系列基本功能。
但由于技术架构的局限性，最初的系统承担着需要管理这些合同模板，而模板则基于JSP页面进行维护。每次新增合同或者合同内容调整，需要后端研发自己编写HTML和CSS，而且必须遵守一定的规范，譬如一行不能多于多少字，否则内容生成或者打印的时候超出纸张。
因此合同模板的管理复杂且成本高，这就带来了每次小小的需求迭代都需要花费很多的时间去人工调整合同内容或样式，而且合同对浏览器的版本有一定的要求，对于一些纸质合同预览或者打印，用户必须使用指定的浏览器。
尽管如此，但负责这个系统的研发可谓劳苦功高，日常就是管理维护这些合同，虽然技术没什么含量，但内心肯定不少骂爹，毕竟没办的。
三、初次革新
入职不到半年，团队人员大变更，负责这个研发团队的VP突然离职了，后续研发团队内部的大部分人员也陆续离职。期间，来了一位新领导，负责我们研发团队，然后带领这个团队开山劈林。
而我作为这个研发团队的老员工，尽管入职不到半年，但得到领导的青睐和赏识，被委以重任负责金融产品系统和GPS审核系统。
新老板肯定不能继续容忍合同系统这种架构设计，因此，合同中心的重构迫在眉睫。车金融业务线有个公共服务，CA系统，提供了各业务线对接，管理合同模板以及电子合同的生成以及签章管理。
就这样，合同系统也开始对接CA系统，以进一步剥离出相关功能移植到CA系统中，本身只关注合同要素数据的获取，以及合同影像文件的业务逻辑存储。
合同系统这样技术架构调整后，对于车金融业务线所关注的系统业务职责也逐渐变得清晰。为了提高应对需求迭代的效率，基于XDiamond的合同要素取值配置在新重构的合同系统（Doraemon）得以运用。
四、历史机遇
新的合同系统伴随着越来越多的资金方接入车金融，但是系统基于Xdiamond配置的形式配置变得越来越复杂，日常维护成本提高。
这种配置基于JSON配置结构，采用Spring SPE表达式实现业务逻辑取值和逻辑路由控制。业务场景的复杂性，同时也增加了配置逻辑的复杂性。
譬如对于同一资方，同一金融方案，但是对于新车或者二手车务逻辑场景控制却有很大的不同，因此公司业务为了扩展多样性以及实现不同地域的差异性，无形中使得这个合同系统容易配置越来越容易出错。
合同系统面临的痛点是，没有一个健全的审核流程发布机制和合同版本控制机制，一旦配置出错，则影响线上的电子合同与纸质合同。
事实上讲，线上也因配置出错导致的故障。一旦出现故障，当我们研发收到故障情况时，时间已经非常滞后。
后来，领导开始安排我负责合同与贷后的需求研发管理工作，对于当前系统存在的问题需要做出决策和方案，对下一步工作做详细的规划，以解决当前系统面临的诟病。
初步带领这个团队，了解当前需求情况和日常管理机制，对当前的研发管理工作有了初步的了解。然后，下一步工作就是健全日常的项目管理机制，完善项目流程规范。
在这一方面做出了如下改进措施：
- 完善项目流程规范机制，通过日常小组会议强调流程规范的重要性。
- 完善项目研发的review机制，需求研发必须做好技术方案预研和评审工作。
- 健全系统的监控和诊治工作，自主研发开发了流量复现和样本覆盖功能，对于线上的发布和检测可以弥补功能测试的短板，进一步保障线上发布质量。
- 自主研发开发了质检中心系统，对于合同与请款做数据质量检测。
诚然，从长远来讲，我们需要对当前合同系统面临的新一轮挑战尽快做出决策，以尽快解决当前面临的问题。
因此，我们研发团队重新梳理了线上的合同业务逻辑和合同要素取值，通过表格化或思维导图形式做出了详尽的梳理并整理到WIKI，对于下一步数据监测和重构系统奠定工作。
同时，与产品团队一起沟通技术设计方案和原型功能设计，对下一步重构工作做总体规划方案。
五、重塑设计
我们摒弃了基于Xdiamond配置的设计方案，是由于我们清晰地认识到，虽然这种配置形式灵活，但是不利于非技术同学的运营维护。为了提高产品同学的方便快捷使用，降低日常运营的成本，因此，我们从交互设计来讲，吸收了金融产品平台的交互设计方案为其所用。
由于不同资方之间合同条文以及业务逻辑的多样性，同为了方便重构后的系统可以方便管理这些合同，在这一方面我们花费了很多构思和想法，为构建一个简单易用的合同系统平台，以进一步提高日常运营效率，快速支持日常业务变更需求上线。
同时我们也要思考另外几个问题，就是合同版本机制的设想。由于需求上线后，对于历史订单的合同则维持原来的业务取值逻辑，但是对于新的订单则运用新的版本控制逻辑。对于这种需求场景迫切诉求，我们在设计合同版本控制的功能设计上，通过团队小组认真研究，做出了不少创新成果。
1.资方管理
资方即金融方案的资金方，不同资金方的合同是有所不同的，因此这是合同系统的第一个大维度，一个资方包含若干合同。
资方的创建，是根据金融产品平台启用的资方进行初次配置的。
2.合同管理
这里的合同管理，即所有资方的全量集合，根据业务划分，有通用类和特殊类两大类。通用类，适用于所有资方，特殊类用于解决特殊资方一下特殊业务场景的应用。
这里的合同，包括自身合同编码，以及对接CA系统的合同编码。CA的合同编码用于调用其系统时，根据合同模板生成合同影像。
同时，合同有一个批次字段，用于标识不同场景阶段所签约的合同，譬如授信阶段或者贷前阶段。
在资方管理可以配置应用已启用的合同集，这里的合同集就是业务规定需要进行签约的所有合同。
3.要素配置
合同创建完成之后，然后应用于资方，即可以对该资方不同的合同配置取值逻辑。取值逻辑可以基于条件场景确定取值配置，多个场景的条件优先级是相同的。
取值配置可以继续数据项或者表达式配置，所有的数据项由系统内部先决决定。
4.要素管理
要素即合同数据字段，一个合同有若干个字段，用来声明合法的字段。这些字段经过填充后，基于合同模板可以最终生成有效的合同影像。
由于要素是合同中最早的业务单位，因此数量比较庞大，所以可以基于不同的组进行管理，以便在合同配置时方便快捷检索使用。
5.版本管理
版本是基于合同管理的，以适用的业务场景的发展需要。
6.模板管理
合同模板最终由产品确定范文内容，然后通过CA系统，上传模板并启用。
7.签章管理
签章即合同上的主体公司，这些签章在CA系统进行管理合同系统调用CA系统，需要声明某个合同的签章关键字。
8.交互示例
六、尾语
一个系统从设计之初，并不可能就是考虑周全且设计完美的。正因为如此，所以我们要不断根据业务实际的发展趋势，不间断地解决系统面临的痛点，重构优化是伴随着从开始到未来，重构优化的目的就是为了系统更好地适应业务的趋势发展，两者的关系紧密相连。
从系统架构的本质来讲，就是通过重构进一步提高系统的扩展性和伸缩性，为迎接下一轮挑战奠定坚实的基础和有效的保障。
标签：今生,系统,业务,研发,前世,合同,资方,模板 来源： https://blog.csdn.net/shichen2010/article/details/109964060
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。