任何一个软件架构设计包括了两个层面的内容，第一个是功能性需求的实现，第二个就是类似性能、安全等非功能性需求的实现。同时也涉及到需要去选择一些底层的技术框架和技术组件来实现最终的应用开发。对于功能性的架构设计要求我们必须懂业务。在业务或者需求分析里面形成相应的业务流程和业务对象。在架构设计阶段你实际是需要将需求的内容做进一步的抽象和转换，转换成技术层面的内容。比如具体业务对象会转换成类的设计，类关系图，或者底层数据库设计。业务用例会转成技术用例，业务流程会转成具体用例设计，在架构设计过程中需要去完成这些转换。
我们常谈的架构设计方法，最早的基于UML，基于4+1视图，可以形成相应的用例视图、逻辑视图、进程视图、部署视图，具体4图设计过程中，最最核心的能力就是分解+集成的能力。任何一个大的业务需求过来之后，我们都需要去考虑应该分解成几个大的组件，每个技术组件本身又需要分解成哪些技术包。当分解出具体组件之后，还需要考虑组件之间如何集成，组件间的接口如何取设计，如何保证每个组件都做到高内聚松耦合。所以架构设计不是分解完就完事，分解完的内容，架构师应该确保能够基于当初定义的接口最终再次集成起来，这才是一个完整的过程。
在架构设计里面，还有一个关键点，我们在做业务分析，用例需求分析过程中，你会发现哪一些不管是业务能力还是技术能力可以服用的内容。对于可复用的能力，我们必须下沉到具体平台层的能力，形成共性可复用技术和业务组件，可复用性也是架构设计里面相关重要的内容。
最后再谈一下非功能架构设计。非功能性架构设计包括了类似性能、安全、可靠性，整个软件应用的可扩展性这些都是核心的非功能性架构设计。非功能性架构设计不足导致后期很难弥补，甚至导致推倒重来。但是在非功能性架构设计中，我们经常走入一个误区，任何一个项目或者应用的实现都应该是选择当前最适合的技术，而非选择最先进的技术。有些架构师完全采用拿来主义，老想着用各大互联网公司最新的框架、组件等技术来时间自己的业务应用。但是这些新的技术本身学习成本高，后期维护成本也高。因此，太先进的技术并非企业所最迫切需要的。
最后要说明一点的是，架构设计最终要解决业务场景，业务需求落地的能力。对于架构师，不是简单输出一个方案，而是要具备将方案传递给开发团队，开发团队基于方案做具体编码实现，最终落地。如果最终架构设计思路和方案没有完成这种传递，架构师的价值是没有体现出来的。
