1 为什么要写技术方案

回顾软件开发的历史进程，我们可以将其分为程序设计时代、程序系统时代和软件工程时代三大历史阶段。

在程序设计时代（1946-1956），软件开发主要依赖于个人编程技巧，技术文档只要存在个人开发者的大脑即可，因为没有沟通和协作需要，编写技术文档也不具有紧迫性。

在程序系统时代（1956-1968），计算机性能显著提升，应用范围和规模逐步扩大，以至于依靠个人无法完成软件的开发，所以出现了团队合作。在早期团队合作过程中，开发者仍然保持了早期各自为战的开发习惯，即使出现了一些方法论雏形，也无法从根本上控制沟通和协作的巨大成本，软件危机就此出现。1968年国际学术会议提出了软件危机和软件工程的概念。

软件危机的定义是落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致开发与维护过程中出现一系列严重问题的现象。软件的工程定义是建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法

从此软件开发进入工程化阶段，也应运而生了大量开发方法论和开发模型。其中标准和完善的文档是软件工程重要组成部分，可以很大程度上减少沟通和协作成本，而技术方案又是技术文档重要组成部分。

2 技术方案要体现什么

软件系统生命周期包括定义、开发、运维、消亡这四大阶段。定义阶段包括定义问题、可行性研究和需求分析。开发阶段包括概要设计、详细设计、编码和测试。运维阶段包括更正性维护、适应性维护、预防性维护和完善性维护。消亡阶段包括系统报废和优雅下线。

3.1.2 四色建模

(1) 时标对象

四色建模第一种颜色是红色，表示时标对象。时标对象是四色建模最重要的对象，可以理解为核心业务单据。在业务过程中一定要对关键业务留下单据，通过这些单据可以追溯整个业务流程。

时标对象具有两个特点：第一是事实不可变性，记录了过去某个时间点或时间段内发生的事实。第二是责任可追溯性，记录了管理者关注的信息。现在我们分析本系统时标对象有哪些，需要留下哪些核心业务单据。

转会对应转会单据，体检对应体检单据，签合同对应合同单据，训练对应训练指标单据，比赛对应比赛指标单据，新闻发布会对应采访单据。根据分析绘制如下时标对象：

(3) 角色对象

在四色建模中用黄色表示，这类对象表示参与方、地、物以什么角色参与到业务流程：

3.1.3 划分领域

在四色建模过程中我们体会到时标对象是最重要的对象，因为其承载了业务系统核心单据。在划分领域时我们同样离不开时标对象，通过收敛相关时标对象划分领域。

3.2 用例看功能

目前为止领域已经确定了，大领域已经拆分成了小领域，我们已经不再束手无策，而是可以对小领域进行用例分析了。用例图由参与者和用例组成，目的是回答这样一个问题：什么人使用系统干什么事。

下图表示在比赛领域，运动员视角（什么人）使用系统进行进球统计，助攻统计，犯规统计，跑动距离统计，比赛评分统计，传球成功率统计，受伤统计（干什么事），同理也可以选择四色建模中其它参与者视角绘制用例图。

3.3.2 顺序图

顺序图侧重于交互，适合按照时间顺序体现一个业务流程中交互细节，但是顺序图并不擅长体现复杂逻辑分支。

如果某个逻辑分支特别重要，可以选择再画一个顺序图。例如支付流程中有支付成功正常流程，也有支付失败异常流程，这两个流程都非常重要，所以可以用两张顺序图体现。回到本文实例，我们可以通过顺序图体现球员从提出转会到比赛全流程。

3.4 领域与数据

上述章节从功能层面和流程层面进行了系统分析，现在从数据层分析系统，我们首先对比两组概念：值对象与实体，领域对象与数据对象。

实体是具有唯一标识的对象，唯一标识会伴随实体对象整个生命周期并且不可变更。值对象本质上是属性的集合，没有唯一标识。

领域对象与数据对象一个重要的区别是值对象存储方式。领域对象在包含值对象的同时也保留了值对象的业务含义，而数据对象可以使用更加松散的结构保存值对象，简化数据库设计。

现在我们需要管理足球运动员基本信息和比赛数据，对应领域模型和数据模型应该如何设计名、身高、体重是一名运动员本质属性，加上唯一编号可以对应实体对象。跑动距离，传球成功率，进球数是运动员比赛表现，这些属性的集合可以对应值对象。

为什么要采用JSON存储值对象为脚本化是一种拓展灵活性的方式，脚本化不仅指使用groovy、QLExpress脚本增强系统灵活性，还包括松散可扩展的数据结构。数据模型抽象出了姓名、身高、体重这些基本属性，对于频繁变化的比赛表现属性，这些属性值可能经常变化，甚至属性本身也是经常变化，可能会加上射门次数，突破次数等，所以采用松散结构进行存储。

如果需要根据JSON结构中KEY进行检索，例如查询进球数大于5的球员，这也不是没有办法。我们可以将MySQL表中数据平铺到ES中，一条数据根据JSON KEY平铺变成为多条数据，这样就可以进行检索了。

3.5 纵横做设计

复杂业务之所以复杂，一个重要原因是涉及角色或者类型较多，很难平铺直叙地进行设计，所以我们需要增加分析维度。其中最常见的是增加横向和纵向两个维度，本文也着重讨论两个维度。总体而言横向扩展的是思考广度，纵向扩展的是思考深度，对应到系统设计而言可以总结为：纵向做隔离，横向做编排。

我们首先分析一个下单场景。当前有ABC三种订单类型：A订单价格9折，物流最大重量不能超过9公斤，不支持退款。B订单价格8折，物流最大重量不能超过8公斤，支持退款。C订单价格7折，物流最大重量不能超过7公斤，支持退款。按照需求字面含义平铺直叙地写代码也并不难：

上述代码从功能上完全可以实现业务需求，但是程序员不仅要满足功能，还需要思考代码的可维护性。如果新增一种订单类型，或者新增一个订单属性处理逻辑，那么我们就要在上述逻辑中新增代码，如果处理不慎就会影响原有逻辑。

为了避免牵一发而动全身这种情况，设计模式中的开闭原则要求我们面向新增开放，面向修改关闭，我认为这是设计模式中最重要的一条原则。

需求变化通过扩展，而不是通过修改已有代码实现，这样就保证代码稳定性。扩展也不是随意扩展，因为事先定义了算法，扩展也是根据算法扩展，用抽象构建框架，用实现扩展细节。标准意义的二十三种设计模式说到底最终都是在遵循开闭原则。

如何改变平铺直叙的思考方式就要为问题分析加上纵向和横向两个维度，我选择使用分析矩阵方法，其中纵向表示策略，横向表示场景：

3.5.1 纵向做隔离

纵向维度表示策略，不同策略在逻辑上和业务上应该是隔离的，本实例包括优惠策略、物流策略和退款策略，策略作为抽象，不同订单类型去扩展这个抽象，策略模式非常适合这种场景。本文详细分析优惠策略，物流策略和退款策略同理。

来源：张建飞（Frank）