软件架构的思考
最近看了公司组织的架构师训练营培训课程，有很多感慨，提升了下自己对架构师的认知，但是毕竟是培训课程，知识涵盖点有限，还有个软件架构本身不是孤立存在的，跟软件工程息息相关，里面涉及到很多方法论、工具、模式的东西，俨然是个综合性的东西，离开了软件工程谈架构，感觉没多大意义，这里就简单的做个总结。
软件工程背景
早在50、60年代，随着软件行业的发展，系统变得更庞大复杂，软件的成本日益增长、开发进度难以控制、软件质量差、软件难以维护，于是产生了软件危机。经过种种分析，软件危机可以归纳为这4个方面：用户需求不明确、缺乏正确的理论指导、软件规模越来越大、软件复杂度越来越高，于是人们吸取传统工程的经验，即用现代工程的概念、原理、技术和方法进行计算机软件的开发、管理和维护，于是诞生了软件工程。IEEE（美国电气与电子工程师学会）给软件工程下了个定义：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
为什么需要架构？
需要架构基于以下原因：
- 理解系统
- 组织开发
- 鼓励重用
- 进化系统
软件工程是一个系统化的工程，需要将分析、设计以及其他开发活动粘合进来，于是就有了软件开发生命周期（Software Development Life Cycle (SDLC)）：
- 可行性研究阶段：软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
- 需求分析阶段：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。
- 设计阶段：软件设计可以分为两个阶段概要设计和详细设计，实际上软件设计的主要任务就是把软件分解成模块是指实现某个功能的数据和程序的说明。
- 实现阶段：软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一段程序设计语言表示的“源程序清单”。充分了解软件开发语言，工具的特性和编程风格，有助于开发工具的选择 保证开发产品的开发质量。
- 测试阶段：在设计测试用例的基础上，测试软件的各个组成模块，然后，在把各个模块集成起来，测试整个产品的功能和性能是否能够满足已有的规格说明。测试阶段有集成测试和确认测试。
- 发布阶段：完成测试后，我们就需要通过部署软件，来方便用户使用了。在此阶段，部署团队需要通过遵循若干流程，来确保部署流程的成功。无论是简单的流程，还是复杂的部署，都会涉及到创建诸如安装指南、系统用户指南等相关部署文档。
- 维护阶段：维护是指已经完成对软件的研制工作并交付使用后，对软件产品所进行的错误改正，适应环境变化和增强功能等软件工程修订，做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以扩展软件功能，提高性能，为用户带来明显的经济效益。
而需求分析和设计阶段之间就存在一条很难逾越的鸿沟，而软件架构就为这两者架起了一座桥梁，针对SDLC出现了很多模型方法如：瀑布、螺旋、敏捷、devops等等，不管哪种演进模式，都需要先有一个抽象化的概念图，虽然架构不能百分百描述出系统，但可以简化系统。
什么是软件架构？
《统一软件开发过程》4.1章节，这本书里UML三位创始人定义了什么是软件架构：
软件架构是一组有关下述内容的重要决策：
- 软件系统的组织；
- 对组成系统的结构元素及其接口的选择；
- 像元素间的协作所描述的那样的行为；
- 将这些结构元素和行为元素组合到逐步增大的子系统中；
- 指导这种组织的软件架构风格：静态和动态元素以及它们的接口、协作和组成。
软件架构不仅关心结构和行为，而且还关心用法、功能、性能、弹性、复用、可理解性、经济与技术约束及其折中，以及审美的考虑。可以用4+1视图表示，如下：
，它的作用就是从需求、设计、实现、部署不同视角能描述系统重要功能。软件架构也没有银弹，其他方式也可以获得成功，但是以架构驱动的开发最有效。
软件架构方法
软件架构方法不是孤立的，而是一个体系结构，软件开发周期每个阶段都有对应的架构视图，这里就总结下目前感觉最有效的一种开发过程模型：统一软件开发过程（The Unified Software Development Process），它的特点就是“用例驱动、以体系结构为核心、迭代及增量”，它的生命周期如下：
- 初始 （inception）是这个过程的第一个阶段。在此阶段，萌发的开发想法经过培育要达到这样一个目标：至少要在内部奠定足够的基础，以保证能够进入到细化阶段。
- 细化 （elaboration）是这个过程的第二个阶段。在此阶段定义产品需求和体系结构。在这个阶段，将明确系统需求，按其重要性排序并划定基线。可以按一般的描述，也可以按精确的评价准则来排列系统的需求，每个需求都说明了特定的功能或非功能的行为，并为测试提供了基础。
- 构造 （construction）是这个过程的第三个阶段，在此阶段软件从可执行的体系结构基线发展到准备移交给用户。针对项目的商业需要，这里也要不断地对系统的需求，特别是对系统的评价准则进行检查，并要适当地分配资源，以主动地降低项目的风险。
- 移交 （transition）是这个过程的第四个阶段，在此阶段把软件交付给用户。在这个阶段，软件开发过程很少能结束，还要继续改善系统，根除错误，增加早期发布未能实现的特性。
需要针对每个阶段进行架构设计：
业务架构：商业蓝图建模
需求阶段：功能性需求，非功能性需求分析，挖掘真实的需求，5W2H原则，使用用例图建模
分析阶段：分析建模，使用抽象概念类图（领域模型）进行静态建模，使用活动图进行动态建模
设计阶段：设计建模，细化3阶段的领域模型，使用具体的实体类图进行建模
实现阶段：搭建项目脚手架、包分层、技术选型
测试阶段：构建测试模型，编写测试用例
部署阶段：构建部署视图
这个过程中，有很多方法论如面向对象设计、领域驱动设计，还有其他工具辅助设计（如UML），但是每个阶段的表现形式都是大同小异的。软件架构方法还有很多，可以取其他架构的一些好的优点集成到自己的架构体系，面对复杂的软件项目，就多一些分析手段，比如重构老项目，面向结构化的架构中的数据流图其实也是一个不错的工具。
参考资料：
