我阅读了一线架构师实践指南，其中结合这具体的实例对具体案例的分析，一步步的讲解着架构在构建过程中的方法，以及步骤。
首先，最为软件的第一步，其肯定是有需求驱动的。用书中的话说就是“需求进，架构出”，架构的设计应该始终贯穿这一条主线。任何软件的工作的进行都必须按照需求进行，在开始设计时必须要认真的分析需求，需求 = 功能 + 质量 + 约束。想想我们在学习过程中对于需求的解释是啥，实际开发过程中我想大多数人关注的也就只是功能了，但是这样的设计往往是一个失败的设计，单关注功能，而忽略其隐含的质量以及约束条件，这样的程序自身就是个bug。
有了需求的驱动，就可以进行架构的设计了。书中将架构的设计分为了三个阶段。
- 预备架构阶段（在此阶段最大的误区就是，架构师是技术人员，不必懂需求，需求分析只要交给需求分析师即可。如果是这种思维就会出现架构与需求严重的脱节，对于一个系统的架构师来说要掌握全局的，他要对所有技术问题负责，所以他必须要熟悉系统的需求，虽然不必参加需求的制定，但是对于软件实际的需求必须是胸有成竹的，这就要摒弃“需求列表”方式，建立二维需求观，需要明确用户需求、系统需求、业务需求以及其对应的质量属性以及约束）
- 概念架构（在此最大的误区就是概念架构 = 理想的设计，用架构漫谈中所说的概念架构就是对整个系统进行划分的第一步，将一个大的系统划分为若干个子系统，进行大的框架的设计，他其实就是将需求划分为了不同的场景，必须明确的考虑，包括功能、质量、约束的各个方面）
- 细化架构（在此阶段最大的误区就是架构 = 模块 + 接口 架构的细化并不是一步的实现，这就是一直强调的要进行划分，要将较大的问题划分为更多的小问题，让每一个问题都有着针对性，而模块接口只是其具体的实现方法，在大型系统的架构分析中必须对架构进行详细的划分，可以用到包图、接口图等进行架构的细化，不能直接想着一步到位直接细化到模块接口层面）
在此书中多次提到的就是对质量以及需求的以及其相关的约束，功能属性这些方面都非常的浅显，对公能分析就可得到，到往往非功能属性的质量以及约束才是评价一个软件、决定一个软件成败的关键。而且，对于质量属性来说不可能达到面面俱到，必须把握一个关键的属性，这是考验一个优秀架构师的重点。只有把握好关键质量，以及主要约束，才能让一个优秀的架构完整落地。