万字长文！多图！结合DDD讲清楚编写技术方案的七大维度 _DDD

1 为什么要写技术方案回顾软件开发的历史进程，我们可以将其分为程序设计时代、程序系统时代和软件工程时代三大历史阶段。
在程序设计时代（1946-1956），软件开发主要依赖于个人编程技巧，技术文档只要存在个人开发者的大脑即可，因为没有沟通和协作需要，编写技术文档也不具有紧迫性。
在程序系统时代（1956-1968），计算机性能显著提升，应用范围和规模逐步扩大，以至于依靠个人无法完成软件的开发，所以出现了团队合作。在早期团队合作过程中，开发者仍然保持了早期各自为战的开发习惯，即使出现了一些方法论雏形，也无法从根本上控制沟通和协作的巨大成本，软件危机就此出现。1968年国际学术会议提出了软件危机和软件工程的概念。

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

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

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

文章插图

生命周期每个阶段固然有各自的重要性，但是开发者更应该关注定义阶段与开发阶段。定义阶段需要解决为什么开发（why）、需求是什么（what）两个问题，开发阶段需要解决怎么设计，怎么编码，怎么测试（how）三个问题。
技术方案是否需要体现定义和开发的所有子阶段？我认为也无必要。问题定义和可行性研究主要由产品经理负责，测试阶段主要由测试人员负责，开发者可以关注但不是必须体现在技术方案。我认为技术方案必须要体现需求分析、概要设计、详细设计、编码四个子阶段。

3 七大维度我认为一份完整技术方案应该至少具有七大维度，每个维度描述系统的一个侧面，组合在一起最终描绘出整个系统，这些维度分别是：

四色分领域
用例看功能
流程三剑客
领域与数据
纵横做设计
分层看架构
接口看对接

本文我们分析一个足球运动员信息管理系统，这个系统我们可能也都没有做过，正好一起分析这个系统。需要说明本文着重介绍方法论的落地，业务细节难以面面俱到。

3.1 四色分领域3.1.1 流程梳理首先梳理业务流程，这里有两个问题需要考虑，第一个问题是从什么视角去梳理？因为不同的人看到的流程是不一样的。答案是取决于系统需要解决什么问题，因为我们要管理运动员从转会到上场比赛整条链路信息，所以从运动员视角出发是一个合适的选择。
第二个问题是对业务不熟悉怎么办？因为我们不是体育和运动专家，并不清楚整条链路的业务细节。答案是梳理流程时一定要有业务专家在场，因为没有真实业务细节，无法领域驱动设计。同理在互联网梳理复杂业务流程时，一定要有对相关业务熟悉的产品经理或者运营一起参与。
假设足球业务专家梳理出了业务流程，运动员提出转会，协商一致后到新俱乐部体检，体检通过就进行签约。进入新俱乐部后进行训练，训练指标达标后上场比赛，赛后参加新闻发布会。实际流程会复杂很多，本文还是着重讲解方法论。

文章插图

3.1.2 四色建模(1) 时标对象四色建模第一种颜色是红色，表示时标对象。时标对象是四色建模最重要的对象，可以理解为核心业务单据。在业务过程中一定要对关键业务留下单据，通过这些单据可以追溯整个业务流程。
时标对象具有两个特点：第一是事实不可变性，记录了过去某个时间点或时间段内发生的事实。第二是责任可追溯性，记录了管理者关注的信息。现在我们分析本系统时标对象有哪些，需要留下哪些核心业务单据。