在进行软件开发之前，拥有一份清晰的软件设计文档进行开发全程的指导十分重要。在软件团队，经常发生人员流动，在完成一个项目的过程中，一个软件模块可能会流经N个人的手。如果没有一分清晰的设计，模块的设计思路经过多人之后可能已经走偏，即使能保证原来的思路进行，中间也势必造成很大的成本浪费。
软件设计的工作属于架构师或可以叫做技术负责人，架构师的职责是保证软件设计可以满足用户的功能性需求和技术发展的非功能性需求，同时完成和各个相关方的人员沟通和系统沟通。在完成一切准备后，架构师就要保证自己团队内技术思想统一，按照达成的共识进行项目开发。
软件设计是软件项目中的一个核心环节，这个过程就是架构师或技术负责人产出技术设计的过程，同时输出产物：技术设计文档。
软件设计的核心就是软件建模，在你建立的各种抽象模型之上，再配上文字说明就形成了软件设计文档。模型是对客观业务的抽象，软件设计就是要解决的各种抽象模型及其之间的对应关系，和其涉及到的业务流程，最后在这些基础上添砖加瓦，组件规划。
软件设计过程又可以拆分成 需求分析、概要设计、详细设计三个阶段，主要用到的工具是UML。如果在一般的迭代形项目中，我建议大家最终形成一份 详细设计 即可，但是详细设计也会是包含了需求分析、概要设计、详细设计的过程，只不过文档最终体现在一起而已，任何一个环节肯定是都是不能少的（当然有些项目需要总体设计等，这里别较真哈）。其中每个环节都有具体的模型工具可以帮助我们，下图就软件建模中常见的几种图以及对应的场景进行使用说明，基本可以涵盖市场上大部分大中小型的软件设计了。
图1 - 10种常用的图使用说明
图2 - 软件设计3个阶段使用的工具
需求分析：
并不是只有产品经理才去做的事情，在一份软件设计设计文档中，需求分析部分体现的是设计人员对整体产品放心思路的把控。比如这个阶段 我们可以用流程图描述业务的具体流转，用用例图标识各个角色的场景用例，用时序图表述场景交互等。
概要设计：
在我们的软件设计文档中，概要设计部分体现在项目文档的最上方， 在经历了一系列的项目需求讨论之后，他清楚的描述了项目的整体架构，以及各模块间的层级关系。虽然他的发生客观意义上晚于需求分析阶段。
详细设计：
这个阶段着重对技术实现的细节进行描述，开发可以根据这部分的内容进行软件开发了。
例如:
-
接口间交互用到的时序图
-
代码实现用到的类图
-
实体关系表述依赖的ER图
-
内部状态流转又会使用到状态图等
真正做了这些，才算完成了一份勉强合格的技术设计。
那如何才能做一份清晰易懂，可供开发使用的软件详细设计？
首先，目录结构要清晰，有清晰的索引才能方便我们后期的使用，方便开发过程中快速的定位到某个模块设计。类似于字典的目录，如果字典没有了目录，这本字典也将变得一无是处，同样软件设计文档也如此。
其次，系统说明也要有，不论是大型项目还是每次迭代型项目，都有其存在的背景，项目的产生一定经历了需求沉淀的过程，一份具有指导意义的设计文档中对需求的描述是必须的，具体体现形式可以没有具体的规定。
再次，设计原则等规范需要提前声明。项目的微观实现有很多方式，可以采用传统的分层架构模式也可以采用领域驱动设计，但是其中有一个概念必须被提出就是 通用语言。通用语言并不是只有领域驱动开发才会用的概念，在很多项目中都会存在很多人对于同一个名词有不同理解的情况，比如取送车（e代驾）模块实现中，取送车模块会关联订单模块，订单一词取送车相关的同事理解成了取送车下单，而订单模块同事理解成了支付订单，如果定义好了通用语言，这个情况就不会发生了。
同时，在这部分也需要体现出系统的设计规则或使用了哪些技术来实现，比如加密方式采用对称机加密或非对称加密，消息传递采用同步还是异步，语言使用java还是go，组件使用springcloud还是dubbo等。这些非业务性的组件作为项目开发的一个工具，可以很清楚的告诉伙伴们应该去学习什么，应该如何使用等。
然后，一切准备完成之后，可以进入正题了。总体设计，在系统设计模块开始，最好可以用一张图或是几张图体现出整个架构的思想，让人可以对此次项目软件设计有清晰的整体认知。比如整体的架构图，流程图，ER图等。其次可以分别针对不同的模块交互进行详细的交互设计，只有一个要求就是直到清晰的描述完成各个的细节为止。
最后，设计可以收尾了，当然在这之前还可以有项目拓扑部署图等等。无所谓了到这个阶段已经开发完了， 性能不够核数来凑，不在部分范畴里讨论了。
抓住以上几个核心点，足以完成一份实用的软件详细设计了。
