前言
由码代码到软件设计，所需要的思维方法发生了变化，某些在码代码时占比比较小的思维方法在软件设计中变得至关重要。
软件概要设计刚开始学习不久，本文仅仅基于本人当前的认识。
大原则
软件设计最本质的原则（在我看来）是经济学十大原理中的第一条：人们面临权衡取舍（trade-off）。
码代码不会有这个意识，在这个阶段接受到的是具体的任务，框架已经选好并搭建完毕了，数据库选定了，相关的技术也都已经定好，要做的只剩下完成某个需求，不复杂的情况 CRUD 就可以搞定，业务复杂的情况下加点设计模式也就搞定了。
软件设计时工程师面临更加复杂的情况。
软件设计定义
根据维基百科对软件设计Software Design 的定义：
Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.
关键词 specification，software artifact， components，constraints
概要设计定义
- A formal description of a system, or a detailed plan of the system at component level to guide its implementation
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
概要设计关注的是组件结构，相互的关系以及设计中的原则和指导方针。
概要设计的艺术
在进行概要设计时需要从抽象、图表、文档三方面进行思考。
抽象
抽象是寻找事务最本质的特征的过程。以前写过一篇抽象的文章，就抽象这个概念进行了一些讨论，此次关注的是抽象在概要设计时所起到的启发作用。
譬如设计一个用户服务，最终设计图如下：
这是经常看到的架构图/设计图，但是设计图里已经将所有的可能都确定了，就像数学题直接给出了答案，无助于了解设计的过程。
真正有助于启发的是在更高一层的抽象上思考服务设计。
在这个设计图上来再进一步思考就到了技术选型的思考于分析，数据存储是选用 RDBMS 还是 NoSQL？Config Server 选用 Spring Cloud Config 还是 携程开源的 Apollo？Request Handling Service 选用 Java 还是 Go？这就需要在当前的环境下来对所有的情况进行考虑，也就是前面所说的大原则：trade-off.
所以设计不是给一个解决方案，而是给出几个选择，再选择中选择最优解。
图表
码代码只需要在头脑中就可以思考所有的情况，然后具现为代码，因为这是单人完成的任务。概要设计则不然，设计完成之后还需要由其他人将其实现。因此设计的沟通属性更强一些。 图表就是利于沟通的强大工具。
在抽象中给出了两个设计图，在作图时也需要时刻记住抽象原则。 判断图表做的好与不好，可分析图表所表现的架构是否是在同一个抽象层次上。
文档
If you can’t explain it simply, you don’t understand it well enough. - Albert Einstein
文档是将所思所想表达出来的载体。如果不能简洁的写出来，那说明你没有完全的了解它。
文档也是梳理的自身的一种手段，就像写博客一样，需要将思考有条理的表达出来，仅仅停留在脑海中是不够的。
总结
不同系统需要不同的设计方案，此文更偏于方法层面，具体系统还需要具体分析。
