背景

在日常业务的研发流程中，因为需求的紧迫性，往往留给研发团队的时间相对有限。这种状况下，旨在确保业务尽快上线，不得不在必定程度上牺牲策划的严谨性和技术的前瞻性，虽然短期内看似办理了燃眉之急，但长此以往，却逐渐累积了大量的技术债务。

技术债，又称策划债或代码债，是指在软件研发流程中旨在追求迅速交付而采用的非最佳达成方法所带来的后续成本。这种“债务”或许源于应用了临时性的办理方案、忽略了代码质量、或缺乏遵循优秀的策划原则和实践。

伴随技术复杂度的逐步提升，系统的可维护性不可避免地遭受侵蚀。这种演变并非线性的递增，而是呈现出指数级的增加动向，最终会致使需求吞吐、交付质量双双下跌。

为进一步提升业务品质和顾客感受，斗拱进件板块确认开启顾客全旅程工程，实施顾客感受的深度改造。但是在整个工程的研发实施流程中，工程师们发觉因为业务逻辑与系统模块的复杂与紧耦合，在研发的时候碰到了较多的难题与挑战，包含研发代码的周期与测试的质量等等，虽然最终有惊无险，顺利完成交付，但是咱们发觉，进件系统的维护与扩展已进入一个新的难度等级，务必开启战略性重构升级计划，为业务可持久进展夯实基本。

难题解析

经过多年的持久迭代投入，斗拱的整套进件体系功能越来越强大，代码量也越来越多，一次完整的进件，要由大量的微业务一同协作完成。从应用架构层面，进件系统可分为：以领域层为复用核心，以功能层为交付重心，以交互层为感受迭代中心，如此的一套三层架构体系：

● 交互层：包含API、WEB页、APP等交互逻辑与业务；

● 功能层：组合领域层原子接口，构成业务功能向交互层输出；

● 领域层：给予抽象过后的原子业务实力，场景关联性弱；

该分层架构在人员配备充足，业务及团队稳定的状况下，是能够充分发挥其策划效能的。然而，伴随斗拱业务规模的持久扩展，面对多产品线高并发迭代的工程挑战与顾客需求的突发式增加态势，研发资产的配置根本吻合不了业务的吞吐速率需求。为确保关键业务目的的顺利交付，局部团队不得不采用敏捷交付机制，在架构策划层面开展必要的动态平衡——经过设立架构治理框架下的技术决策机制，许可在关键路径上实施阶段性灵活调节，与此同时为体系化重构预留技术窗口。

其次，在推进支付系统化建设的战略进程中，因为缺乏成熟的范式可供参考，咱们特地组建了专门的技术委员会。面对各行各业的多样化需求、各类顾客角色另有纷繁复杂的场景故事，怎样在一套系统上达成那些功能，变成了委员会频繁讨论的焦点：是沉淀复用依然个性化定制？是仅思索某一端依然全面支撑全体端？是做到交互层、功能层依然领域层？各方观点不一，但都有其独到之处。

长期运作下来，进件系统各层级，都在大规模的并行迭代，以致于：    

第一，顾客交互层与功能层之间，呈现了对比多的冗余逻辑，加剧了系统的复杂度。

第二，功能层与领域层之间，也现存相似的重复代码现象，技术债务累积。

再者，功能层首要由治理业务和查询业务两个团队负责。其中，治理业务涵盖了顾客感受的方领域面，包含但不限于进件材料与流程、业务配置与开通、协议签订，另有一系列配套的运作支撑功能。那些功能不但要吻合标准化的业务需求，还需兼顾顾客的功能感受和重点顾客的个性化定制。伴随时间的推移，治理业务逐渐变得愈加庞大复杂，后续的维护与扩展难度也随之逐步增加。

最终，治理业务变成了交付瓶颈，需求越积越多。当新增顾客全旅程如此一个极其大的业务实力时，咱们来到了复杂度指数上升的边沿。

重构思路

重构（Refactoring），即还技术债，是指在不转变软件外部行为的前提下，对软件内部结构开展优化和调节的流程。其首要目的是提升代码的可读性、可维护性和可扩展性，从而减少后续研发和维护的成本，提升交付质量和效率。

论及重构，领域驱动策划（DDD）无疑是最先映入脑海的方法论。没错，咱们也正是借助DDD的战略策划，对子域开展了重新划分，构成商户、审核、协议等子域，经过DDD的战术策划，将若干共通的逻辑提炼出来，构成业务权限、计费等模块。

领域驱动策划（Domain-Driven Design，简称DDD）是一种软件策划方法论，它着重以业务领域为核心开展软件策划，经过创建充足的领域模型来反馈业务逻辑，从而达成业务和技术的统一。

整个重构落地也是极其复杂，旨在确保业务持久性不受作用，咱们经过系统化、工程化的手段，分批次开启工程实施。整体分为两大阶段：

阶段一：领域拆分与沉淀

1、原斗拱进件板块，按照DDD的策划思想，重新开展领域的划分；

2、按照新的划分(子域A、子域B...)，将交互层、功能层的逻辑沉淀到各个领域；

3、扩充领域职能，使其不但给予内部业务，与此同时给予对外的API及应用组件；

核心思路：把原先按功能职责拆分的横向切分架构，重构为按领域职责拆分的纵向切分架构，如下图所示：

阶段二：领域模块升级优化

1、在每个领域内，针对较难维护的领域模块，开展二次重构、升级、优化；

核心思路：各个领域团队内部不定期发起重构（或许大或许小），升级优化自身负责的系统代码，提升其可维护性及可扩展性。

本篇文章中，咱们首要探讨阶段一，后续的重构文章系列中，咱们再逐步探讨阶段二的技术故事。

领域拆分与沉淀

1、领域划分

在开启重构之前，至关关键的是要开展广泛而深刻的沟通与沟通，以清晰各个领域的界定、内涵及其边界。这一流程中，咱们应用DDD方法论，围绕顾客故事对上层业务的业务逻辑，尤其是功能业务开展全面梳理。此环节需大量业务专家及系统负责人的主动参与，经过多轮次的讨论与碰撞，最终达成共识，并清晰各领域的负责人。

接下来，咱们将斗拱进件的对外API接口清单、控台页面菜单、内部功能业务接口清单逐一列出，并依据其所属领域开展归类。关于那些与此同时涉及多个领域的页面、内外接口，就由熟悉相干业务的带领依据其经验作出决策，给到最合适的领域。

一旦确认了领域归属，接下来的任务便是从代码层面着手，对全体的API业务、页面及BFF（Backend For Frontend）业务、功能业务开展改造与迁移工作，将其合理地拆分并沉淀到各自对应的领域业务中。

2、代码实施

整个代码实施流程，分为五步：着色->代码拆分->业务拆分>数字库拆分->整理&优化。

步骤一：着色

对后端BFF业务、功能层业务中，全体Public的API方法、Service方法、Repository方法等，添加自界定@Domain注解，以标识其所属领域。关于被多个领域与此同时应用的公共方法，要么标记多个领域名称，要么标记为All，即全体领域。

阐明：此流程同样涉及大量讨论与沟通。旨在最终达成共识，提议按固定一个人的拆分思路统一开展，呈现争议由其来拍板，以免陷入无休止的争辩而无法说服彼此的局面。

步骤二：代码拆分

在不转变业务化结构另有微业务调用入口的前提下，将@Domain标记的代码及其递归引用的私有代码，整体复制到为各个领域新建的独立工程目录中，此时需修改方法给予方及方法调用方相应的import包路径，标记多个领域的方法就复制多份，标记为All的公共方法，就每个域都复制一份。

阐明：这个流程对比复杂的地方是依赖识别，咱们是在Idea插件的基本上自主研发工具达成的。迁移完成后，新版本在生产环境中运行至少两周，以验证其稳定性和可靠性。

步骤三：业务拆分

在调用入口不变的前提下，将跨领域的内存调用代码，转成微业务远程调用代码。此时，微业务的数量会显著增加，大致等于被拆分微业务个数乘以领域数量，此时每个业务就能够独立迭代需求了。同样，该流程也是经过工具完成，微业务调用代码是按统一模版格式生成的，所以类及方法的命名会现存若干不人性化的状况。

阐明：这个流程会遇到对比多的难题，如：内存全局变量难题、数字库事务难题、抽象继承类难题、异步通知难题、超时时长设置难题等，咱们在后续的重构系列文章中再行展开。迁移完成后，新版本在生产环境中至少稳定运行两周，代表该阶段的完成。

步骤四：数字库拆分

为各领域创建独立的数字库，并将各领域独有的库表及数字内涵迁移至新库中。针对那些跨多个领域的共享表，则要开展数字拆分与迁移，该一步骤相比前面的代码拆分、业务拆分，工作量和复杂度都有显著上升。鉴于该步骤短期内难以完成，与此同时思索到以下实际状况，咱们确认暂时搁置，将来择机实施：

● 对全体数字库表，开展领域归属划分，每张表仅归属一个域，针对该表的结构及关键数字变更，均由所属领域团队完成，避免引入跨领域协作难题；

● 在业务拆分阶段时，大局部跨领域的数字操作都已转成微业务调用，只有少数因性能、事务等考量的查询，径直经过Mapper跨库访问。

● 跨域共享表的数量不多，由其他域代为维护的规模不大，复杂度尚在可控范围内；

步骤五：整理&优化

拆到各个领域的微业务，整体是包含了原后端BFF业务、功能业务整体的源代码，工程包极其大，类也极其多。各个团队需求手动整理那些代码，剔除不属于本领域的局部另有未被应用到的函数和方法。此外，关于那些在业务拆分阶段引发的工具型微业务接口，咱们应用@Deprecated注解予以标记，清晰表示那些接口不再接收迭代更新，若将来有需求要迭代，则按照标准的接口标准重新策划实施，以此逐步淘汰工具型的接口。

3、重构成效

在历时三个多月的工程实施流程中，咱们遇到各种各样的挑战，也逐一克服。整个工程的复杂度极高，参与进来的都是各团队的核心成员及众多资深架构师。最终，工程也获取了令人瞩目的成果。

从业务角度统计，进件相干需求的交付吞吐率提升了30%，缺陷密度（上线100个需求引入的缺陷数）下跌30%。

从技术层面来看，日常需求的协作形式从原先前端、功能和领域的多方协作，演变为单个领域团队为主；全体原领域层研发人员全面参与到业务研发中，显著提升了他们的业务经验；全体技术TL主动参与了领域边界的讨论，对各自边界有统一清晰的认识，很少再呈现边界争论；原功能层的治理业务，在经过重点拆分和沉淀后，系统的维护复杂度明显减少。

归纳

斗拱进件体系的重构实践，充分彰显了直面技术债务的关键性。经过缜密规划与严谨实施，咱们不但达成了重构的目的，还显著提升了业务和技术效能。这不但是对技术架构的一次优化，更是团队协作实力与技术实力的全面提升。