https：//blog.csdn.net/fs1360472174/article/details/80961031

摘要

本文主要介绍当随着业务的不断发展，原本一个服务的内容需要抽象出另外的服务，作为中台服务，提供给各个业务前台，提高前台业务开发效率。

业务架构

随着业务的扩展，一个服务的代码越来越多，启动越来越慢，开发的人数越来越多，不得不进行代码拆分，早期有些拆分是按分层拆分，将data,dao层拆分成公共jar，然后很多服务调用，结果导致的就是后期无法维护，业务增长了，分属于不同的开发组了，本来每个开发组的职责都是内敛的，只开发自己那块的就可以，但是现在对于其他组的业务也得熟悉，因为没有共同的服务提供出来，都是自己查库，写库的逻辑改了，有可能会影响到很多地方。所以正确的做法是各个业务按照领域划分，只负责自己的业务部分。

重构过程

重构过程一般分两大部分，一个部分是收集现有的需求，进行领域模型设计，成为一个中台服务，另外一个部分就是迁已有的代码。

一. 中台领域模型设计

对于一些业界比较成熟的方案，这个是很容易划分职责，区分边界的，比如电商领域，淘宝都有书籍出版出来了，按照订单，支付，商品，库存，计价等中台设计即可。但是对于自己公司本身的业务，这个可能很难找到现成的参考案例，需要找到公司自己的业务人员，沟通来确定领域设计

二. 迁移老代码

一般按照3步走，将迁移服务的影响降到最低

迁移写，双写先迁移写，确保写入中台的部分不会出错，这一步上线了新服务，确保了前台业务调用正常。同时将老数据迁移需要有个迁移表，记录两边数据迁移过程双写是以写入老服务为准，写入新服务异常，出现异常，都是catch注，打入log，记录异常原因

迁移读首先需要将写改为写入新服务为准，老服务备份。同时将读改为从新服务读

下掉写1，2都没问题后，将写入老服务下掉。

需要说明的时，这种迁移和数据库分库分表的迁移有些不同，第一点数据库分库分表的拆分一般是同库，表结构的一般只是增量变更，不会更改已有设计，而中台通常伴随着的是领域重新设计，从数据库，到服务层都会有变更。

重构经验

代码分层

很多时候在开发的时候会烦分很多层，因为就是一个CRUD操作，但是随着业务的复杂，这个就很有必要了

ut

bean为不为空说明

bean在各个层级传递时，没有标明是否为空时，重构时很容易出现空指针