类似汽车是现代工业皇冠上的明珠，架构设计也算是软件行业这座高山上的顶峰；类似每一个有理想的攀登者都希望登上珠峰一样，每一个有想法的软件人员都想登上架构设计这座山峰上看一看，而总结是一种攀登的方法。
问题：架构设计是什么问题？
学习软件技术的过程，就像是一个打怪兽的过程，从最开始的语言语法，到框架中间件，再到设计模式系统运维，然后到业务需求架构设计，最终到为业务产出物负责，这个过程伴随着专业技术能力成长，也伴随着思维方式方法的提升。在这个过程中有一个魔咒伴随着，这个魔咒就是“什么是软件架构设计？”。
如果要回答什么是软件架构设计，就要先把这个问题定义清楚，不然怎么回答都是错误，因为软件架构设计本质是一个多维度问题，多维度的问题必然有多种答案，定义好问题才能有正确的答案。
架构设计原点
首先要定义问题，从外部收益角度分析，架构设计做好谁能获得收益，下面是一种收益链，逆转收益链收益的起点和终点分别是用户和研发，所以本质是如何让用户用的更好，如何让研发更好的开发。
- 研发人员专业技术收益，能够使用更专业的技术持续迭代；
- 软件系统本身收益，能够有更好的稳定性扩展性；
- 公司项目收益，能够有更好的产品销售；
- 用户收益，使用的系统更好。
支撑业务技术
然后从问题定义推论，用户+研发实际就是业务+技术，如何支撑业务发展和技术迭代，这两个因素是交织在一起的。这里面对于软件研发人员有几个现实的问题。
- 业务是谁的？
- 技术是谁的？
业务是属于用户的，技术是属于行业的，绝大部分研发人员所做的是研发而不是研究或者创新，研发就是用已有的行业技术实现用户要求，以Java举例，现在Java后端研发的框架或中间件基本定型，Spring全家桶+Redis+MQ+MySQL再加个微服务技术架构，研发人员发挥的空间越来越小（不绝对），这部分不展开论述。
业务技术映射
最后回答这个问题，架构设计是软件技术支撑用户业务发展的一种方法。软件架构设计有一种重要思想是分层，业务和技术也不是单点而是分层的，技术上的分层有硬件网络底层、软件系统中间件、业务系统研发和用户终端使用等，每个层面都有不同的约束。架构设计是研发将业务通过技术实现的一种过程性产物。
回答：架构设计是将多种业务映射到分层技术上的一种方法，做架构设计的人就是做映射的人。
架构设计 = 架构 + 设计。 架构设计是一个多维度问题，当然也有多种答案，网上很多文章都在讲解什么是架构，比如框架、中间件、代码设计模式和微服务等，这些确实属于某一维度架构设计，但是我想总结的是“设计”，怎么将用户的“业务需求”结构化的映射到”技术架构“。
在架构设计之外还有团队规模、人员能力和项目规划等非技术专业因素，毕竟架构设计是一种业务落地的方法，衡量成功与否的重要标准是业务的落地性，这也是研发区别于研究的一点。
