软件技术改方案文档模板

1. 2. 3. 1. 2. 3. 通常情况，技改方案要面对的问题其复杂度要比新应用和一般的功能优化要高。在保证业务发展不受影响的大前提下，即要结合历史现状解决痛点，又要着眼未来的整体规划和布局，还要尽量做到可以小步长的快速迭代，不断进行局部治理 。所以有价值、有规划是前提，稳定性、兼容性是基本要求，有时还要考虑做到可切换 、可灰度等上线和应急策略。 技改要做的好，技改文档和方案评审非常重要，而写技改方案文档，其关键有三点：

关键信息表达清楚；

控制合理范围；

关联性分析、安全性分析、测试分析等尽量的全面。

在下文中，我将之前若干次技改方案文档，涉及到必要内容进行了合并，形成一份较全面的技改方案模板，并简单介绍各个部分的作用和表达方式。PS: 并不是设计文档一定要面面俱到，从中参考必要的部分即可。

价值分析

价值分析是重中之重，立意不详，何谈方案。价值分析通常可以包括以下几点：

本方案改进内容，属于哪些规划中的那些部分或环节，在整体规划上的价值和作用（背景介

绍）

解决哪里痛点问题，包括业务痛点、技术痛点（核心价值）

还有那些后续的迭代安排和规划、可能的发展方向以及可继续挖掘的价值（增值空间）方言定义

为了方便理解，尤其是业务需求与技术实现之间建立有效的关联，需要对一些关键字进行定义和解释。

对一些核心模型进行定义和强调说明

对相关参与者定义进行明确说明

对于一些简称和专业术语进行解释

业务模型设计（领域设计）

业务模型设计分析，是以面对对象思想解构和转化业务需求的关键环节，建议以领域驱动的思想，对业务对象和活动，进行明确的领域划，并对领域之间的交互和依赖关系，进行相应的交互设计。并不要求完全搞懂DDD，但是SOA设计理念出发，面对对像设计思想，都是相通的。所以业务架构和应用架构层面的设计，都围绕领域模型的边界和关系展开，才更利于业务规划与技术规划协同以及架构和代码防腐。

几点小建议：

不管业务逻辑是否复杂，领域划分，业务模型颗粒度、层级划分都值得深思，发掘事务的本质；

如果业务逻辑比较简单，核心业务模型可以是简单的POJO 或 Entity（贫血模型），但注意尽量避免模型继承，尽量遵照【合成复用原则】，采用模型组合。

如果是业务逻辑比较复杂且多变的业务域，其核心业务对象模型，通常需要为业务流程以及活动提供更多的描述和记录支持，所以要避免【贫血】（当然也不建议过度充血），建议核心业务模型作用域能涵盖业务流程整个生命周期。核心业务模型可以由三类对象组成：业务实体对象（Entities）、状态对象（考虑使用状态模式对状态对象进行扩展）、值对象（value）。

关键枚举和状态机 （模型生命周期管理）

软件系统通常都会创建一些状态类的枚举，这部分建议以表格形式，将状态和枚举项罗列清楚。如果业务状态较负责，可以加上UML状态机图，来描述业务模型的状态迁移过程。

用户用例设计（用例图）

如果技改方案涉及【人机交互】部分，需要进行一定的UI交互设计，此时需要先明确【参与者】，这块需要注意的是，通常除了需求描述的直接参与者，还有一些间接参与者。

例如用户个人信息管理，直接参与者是【用户】，关联参与者可能是【运维人员】，可能需要代理用户进行处理，或后台协助用户处理（个人建议所有的前台场景，都要考虑下中后台配套的操作场景设计）。

如果PRD文档已经描述了用户用例图，此处的可以省略。如果技术驱动而不是需求驱动，则最好进行描述，方便和业务方确认。

业务流程设计（活动图）

业务流程设计由两种表达方式，一种是应用流程图，一种是活动图。说说两者的区别： 应用流程图，是从程序执行的过程角度，主要表达执行的步骤和过程。偏技术实现的视角，适合与技术团队沟通。活动图，更适合以业务设定的执行步骤进行表达，表达内容往往更贴合需求描述，适合技术与产品或业务人员沟通。所以这部分推荐以活动图的形式来描述，且尽量去除技术语言和应用模块的定义，仅以step by step的方式描述做什么，这个可以参考可视化工作流模板。根据个人经验，研发人员通过构建活动图，对业务理解和抽象非常有帮助。

研发设计

系统交互设计

微服务体系而言，系统交互设计应该以【应用】为最小粒度，通过关系图的方式来表达【应用】与【应用】之间的关系。 需要重点突出当前应用处于平台或关键体系中所处的位置。当然如果当前技改涉及的范围比较小，粒度也可以适当下降到应用模块的级别来表达交互关系。

应用架构设计

要表达你的应用架构设计，推荐以应用内业务模块、功能组件模块为基本单元，以分层结构图的方式，表达出应用内部的技术架构，例如Facade层有哪些对外服务的功能模块，业务层有哪些业务功能模块，内部领域核心有哪些领域标准服务模块，持久层功能模块等。

通常，应用架构设计，对应着一个软件工程的分层、分包、甚至是maven 模块划分的方式。需要注意的是，模块的粒度，不要太细。可以最小要对应到java package级别。

关键流程时序

关键流程时序图，是技改方案最直接、最容易理解的表达方式。 对应上文的 系统交互设计进行一下说明：

系统交互设计，可以仅表达系统之间存在关联，用于提现系统集成情况；

关键流程时序，必要时也提现系统之间的交互，而且提现调用链路，执行顺序等详细信息，面向实际开发实现细节。 所以个人建议，一定要把时序图画清楚。另外需要注意的是，时序图的各个item，颗粒度要一致，如果是系统级别，就要都是系统，如果是模块就都要是模块，切忌不要混用，容易造成误会。

存储结构设计

存储结构设计，要考虑存储介质选型和模型设计。

存储介质选型，基于不同的业务特性，选择一种或两种存储介质，如Mysql、Mongodb、

ElasticSearch、CouchDB以及缓存Redis 、memcache 等。

数据模型设计，关系型数据库有的数据模型以及关系设计，非关系型数据库的文档模型对象设计，根据业务需求来定。

兼容性设计

兼容性设计，主要考虑两个方面，与其他系统交互的兼容性，历史数据的兼容性。

交互兼容性： 如果服务接口有较大变化，依赖方又不能同步改造，就需要做好接口兼容策略。

数据兼容性：历史数据需要处理，还是新旧数据模型同事存在，逐步同步融合，也需要做好相关的上线前、上线中、上线后相关处理方案的设计。

分布式风险

方案中涉及的逻辑或业务数据，在分布式场景下，需要慎重考虑，是否要分布式锁和最终一致性高保障，尤其是如果存在高并发的情况，更要做好性能和一致性的平衡策略。

幂等设计

幂等性设计，要求服务接口的调用请求，允许被重复执行，尤其是微服务架构下，业务链路较长时，中间服务如果存在重试或补偿机制，用于处理局部失败，链路下游服务几口如果不具备幂等性，业务数据存在被污染的风险，所以幂等性设计是非常有必要。

测试分析

单元测试用例

如果时间允许，强烈建议开发人员做好单元测试分析，设计好单元测试用例。

从项目之处就累计单元测试，方可形成持续高质量交付。

接口测试用例

对于微服务而言，通常通过接口测试，来保证当前服务的质量；而接口测试分析，也是对当前服务能力的全方位理解和检查。更是持续交付持续集成高效率的有效保障

很多日常维护工作效率高不高，就看接口用例全不全

场景集成用例

关联回归用例

在单元测试、接口测试已经有一定积累的情况下，还需要列好回归范围，和包含的回归用例清单。

风险评估

风险评估是最考验业务掌控程度和服务实现水平的环节。

众所周知一个腐败的平台或应用，一些小改动都可能带来很大的风险。

遗憾的是，日常工作中不得不面对这样的改造任务，所以风险评估需要慎重对待。

数据影响范围

服务影响范围

存储容量分析

并发性能分析发布策略发布策略

数据处理

线上回归策略

回滚预案