一个项目的顺利推进，缺不了前期的方案制定，也必须后期的正常落地执行。本文，从制定方案为出发点，从如何制定方案，如何编写方案，到如何推进项目进度作简要记录。

一、制定方案

项目的推进，不管是重构还是新项目的推行，都需要前期调研去了解当前的现状，然后根据现状去制定项目设计方案。而方案的结构化表达是保证项目顺利进行的试金石，方案作为各业务方之间的沟通媒介，将会作为重点文档进行信息对齐，所以方案的整体要有脉络，也方便及时发现、暴露、解决更多的问题，

1.1 了解业务现状

项目的业务背景是我们调研方向的第一着手点，从落地点开始扩展到领域模型，领域模型最开始是非常难以搭建的，所以可以从项目的核心业务出发，总结出底层的能力，然后构建出基本的领域模型，之后按照领域模型的实体去拓展实体管理能力，最后看到整体的业务模块能力，从而可以基本摸清项目的业务边界。

1.1.1 业务领域模型的建立

其实，领域模型的搭建是最核心的部分，必须要非常了解业务现状才可以了解出当前业务的痛点，从而才能知道解决什么问题，不可以为了重构而重构，重构项目可能会带来更少的代码和更稳定的项目。但是如果一味只是为了重构而重写代码，是一件很耗费精力和时间的事情，所以为了使ROI（Return On Investment）最高，我们必须去了解现状，了解业务是什么，有什么能力，为什么有这样的能力（如何实现）？

了解业务现状的时候，刚开始都是很乱，这个时候需要划分模块，按照区域去了解业务，而了解业务本身可以参考快速了解系统业务边界，分区域模块的过程就是构建领域模型的时候。其实是可以把所有的实体都记录下来，然后按照能力区分出哪些是核心能力。了解业务的时候一定要多记录，之后整理材料的时候会反复多次的去确认某个细节点，记录会省掉一些时间。

1.1.2 领域核心能力

领域模型基础建立之后，就需要去了解领域核心能力的细节，需要去了解业务之间的联系，尽量的去抽象能力，去思考业务之间是否能统一模型，构成一个组件。

1.2 业界领域模型

在了解项目的业务边界之后，我们需要去了解当前业界的一些经典模型，以及业界实际应用的模型，总结出模型的优缺点，之后结合现状对比每一种模型，验证实际业务中是否可以适配该模型，如果不可以，改如何修改方案，也就是可以发现本次项目的痛点和创新点。

1.3 痛点

在了解业界领域模型之后，可以基于对现状的了解，总结当前现状的痛点，以及将要解决的目标。

1.4 解决方案

解决方案就涉及到新项目的领域模型和核心能力，重点是实现能力统一，在设计的时候一定要注意追求共性，设计很容易混淆实现，这时候一定要区分出多个模块之间的区分，如果没有一个很好办法，可以试一下从属性和能力两个方面去总结，从而确定是否有共性。

解决方案要包括：

领域模型设计

业务、架构设计：

业务架构：更多的是业务能力，它的下游服务能力和上游服务能力，更多是是服务之间的能力支撑。技术架构：总结起来是指三横三竖藏宝图，

1. 三横：从下自上是基础、中间资源层、应用层。基础一般指的是网络、计算、存储三大块；中间资源层指的一般是消息中心、任务调度、大数据操作、数据流操作、数据资源池等；应用层，指的是最后的业务接入方。
2. 三竖：
   a. 左侧是运维系统，统一日志、统一告警、统一巡检等统一能力，要做一个共享的技术底座；
   b.中间是三横；
   c.右侧是安全系统，全栈的安全（认证、权限、漏洞等）；

存储模型：库表设计
核心能力接口设计：核心接口能力设计，重点要讲清楚系统流程，可以采取时序图，方法只是一种形式。不仅要将自己服务内部的主要流程，还要将与其他服务的交互。
```
  个人理解：流程中一定是包含了双写迁移的过程，如果下掉双写其实设计的就是与现有系统无关的。
```

1.5 迁移方案

项目的推进，最开始的时候是为什么要做，后来是做的过程，最后是收益。其实，项目最重要的就收益，有收益可谈，一切都会推进的相对更加顺利一点，所以沟通的时候一定要抓住收益。除了迁移的沟通需要注意之外，还需要保证迁移方案的准确性，迁移指的是迁移数据，所以不可避免的是要保证迁移数据的一致性，和数据的时效性。

1.5.1 迁移注意事项

1.5.1.1 迁移沟通

对于项目的迁移方关注的更多的是无感迁移且可以获取收益。那么什么叫无感迁移呢？在我的理解里就是，我只需要改一个调用包发布就可以实现迁移，但这种都是理想，现实往往很少是这样的迁移，但是不耽误我们在实现项目的时候不按照最高标准去进行，所以，在沟通的时候，我们也是尽我们最大努力来为迁移方减少工作量，提高彼此的收益，强调彼此的共同点。

1.5.1.2 迁移技术

数据的一致性和时效性。

1.5.2 制定迁移方案

迁移方案的制定并不是一个文档，而是为了项目的顺利推进，平滑迁移，将迁移风险降到最低的保障。

迁移的对象是数据，包括数据的存储和数据的读写。数据迁移指的是将数据从一个系统转移到另一个系统。如果只是一个离线数据库，并不在乎数据的一致性，不用设定迁移方案，随便迁。但是如果在意数据一致性的话，则就需要考虑到数据迁移的时候由于数据不一致导致的损失。简单的数据迁移就是脚本或者定时任务进行数据同步，但是这种方案只能对数据一致性要求低。如果是大数量的实时在线系统的话，则需要保证在线迁移的时候保证数据一致性，且可以回滚。但由于数据迁移实际会有数据的写入，所以回滚，一般就是数据覆盖。

为了平滑迁移，其实可以分为事前、事中、事后。

事前：是备份数据。

事中：具体的迁移方案。

事后：配置监控报警。

事中的数据迁移一般采取的方案是双写，主要有以下步骤：

同步：主要指的是将旧数据库中的存量和增量数据都刷到新数据库中，比如，如果旧系统用的是MySQL的话，就可以使用binlog监听工具获取MySQL的全量和增量日志，不断写入新系统。
双写-》校验：双写指的是业务系统不仅写入旧数据库，还写入新数据库。因为写新库对现有业务整体流程并无影响，所以无需考虑灰度写入，虽然可以，但没必要。写入可以校验数据一致性。
双读-》校验：双读指的是业务系统不仅可以从旧数据库中读取，还可以从新数据库中读取。因为读新库对当前现有业务流程并无影响，所以无需考虑灰度。
切读：下双读，也就是将读链路切到新库中，因为会从新库中读取数据，而新库的稳定性或者整体的架构都不是很清楚，所以从新库读数据可能会有数据不一致性的问题，所以需要灰度放量。每次放量校验数据，稳定之后可以进一步放量。而且先切读对整体项目推进造成的影响最小，因为读不涉及到数据的改动。
切写：下双写，也就是将写链路从业务系统切到新库中。最好能配置监控，实时监控数据的一致性问题，如果不一致则及时告警。先止损。

2.编写文档

方案一般按照总分总的格式来写，这句话其实大家都知道，但是在落地的时候还是有不同。我觉得原因有以下两点：第一点是由于经验的不足导致写文档的时候并不知道该如何写，而网上的格式也是可以参考，但很多的格式都太过繁琐，应用到实际反而缺了一些实践，让人感觉太过理想化。其次，我觉得是目的不明确导致在写文档的时候并不知道该如何下手，比如，在重构账户中台的时候，最开始的时候，只是对重构有一个简单的概念，也不了解具体要做一些什么，所以按照网上的文档格式写了第一版重构方案，也是按照现状分析、痛点分析、方案设计等这样的格式写的，但是还是在沟通方案的时候感觉到力不从心。每个细节点都太碎太糅杂，想讲的很多，导致什么都讲不清楚。

所以，在写文档的时候，一定要有模块有章节，有结构化的表达。比如，账户中台虽然没有一些现成的框架或者模型，但是它是可以拆分多个模块能力的，账户中台一定有基础管理能力，例如CURD能力，登录登出能力等；账户中台之后由于业务的发展才会涉及到账户权限、账户资质和账户鉴权。这些都是可以抽象提取出来模块化的东西，所以我们可以在写设计方案的时候按照模块的东西，细分领域去表达。

总结：如果要用一句话来说重构方案的制定的话，那就是：按模块领域去了解现状和设计方案以及编写方案。

重构项目指南