架构师笔记，软件架构设计

架构设计是分与合的艺术

通读并总结了温昱老师的《软件架构设计》，并有幸听过李哲珠博士对架构设计的讲解。对其读后的自我领悟并提炼出核心内容分享出来，希望从思想高度上能提升你对软件架构设计的认知。

架构设计

架构设计不等于框架设计，框架也可能有架构，所有的原子组件(被拆分的模块)都需要架构设计，所有组件可以组合成复合组件，组合而成的组件也有自己的架构。最简单的架构模式就是适配器模式，因为原子组件随时可能被替换，或接口不统一。

两视图法

三个原则

架构新手和有经验的架构师的区别之一，在于是否懂得、并能有效地进行概念架构的设计。作为架构新手，尤其害怕碰上自己没做过的系统；系统较大时，一旦祭出“架构 = 模块 + 接口”的法宝却不太奏效，架构新手就往往乱了阵脚。相反，有经验的架构师不会一上来就关注如何定义“接口”，他们在大型系统架构设计的早期比较注重识别1）重大需求、2）特色需求、3）高风险需求，据此来决定如何划分顶级子系统、采用什么架构风格和开发技术、集成是否要支持、二次开发是否要支持。

六个成果

三大阶段，分别遵守三个原则，六大步骤可以得到六个成果（每一阶段两个步骤）。

一定要全，必须涵盖功能、质量、约束这三个方面

两纵：第一，沟通功能需求。第二，确定非功能需求（性能需求、便利性需求、友好性需求）

三横：第一，上下文图（待开发系统作为黑盒在中心，周边都关联了哪些系统、环境和活动）

业务决定功能，功能决定模型

领域建模的目的：透过问题领域的重重现象，捕捉其背后最为稳固的领域概 念，以及这些概念之间的关系。在项目前期，所建立的领域模型将为所有团 队成员之间、团队成员和客户之间的交流提供共同认可的语言核心。

领域建模的形式：可以用类图或者状态图也可以用文字

1. 类图：描述静态的关系（一对一、一对多、多对多。继承，关联等）
2. 状态图：描述动态的变化（从某一个状态变为另一个状态，能做哪些功能，在静态完成后着重考虑）。此项分析能够挖掘更多的需求，避免后期的变更（例如：公司-雇佣-雇员，因为雇员会有状态的变化，所以产生雇佣）
3. 文字：直接描述一个具体的模型（位数、格式等规则）

领域建模将对界面设计、持久化数据模型、类设计、可扩展性等方面提供帮助

关键需求决定架构，其余需求验证架构

对功能需求和非功能需求进行筛选，最终确定对软件架构起关键做用的需求子集（占总需求的20%左右）

1. 确定关键质量：确定关键质量时考虑质量数型之间的矛盾关系：性能-安全性
2. 确定关键功能：关键功能涉及（或串起）的模块最多、协作方式最有代表性

关键需求受项目级别影响（部门级应用、企业级应用、集团级应用），同一个项目关键需求可能不同

是直指系统设计目标的设计思想合重大选择

是关乎任何复杂系统成败的最关键的、指向性的设计

需明确给出以下一个决定和四个选型：

1. 如何划分顶级子系统（面向集成的集成模块、为性能把访问资源隔离的各个子系统）
2. 架构风格选型(B/S、C/S、B/S+C/S。。。是最简单的风格)
3. 开发技术选型
4. 集成技术选型
5. 二次开发技术选型

利用五视图法进行设计

一个真正可以运行的应用程序

五视图法

复杂的项目，两视图法就不够用了

1. 模块划分
1. 水平分层
2. 通用模块、通用机制
3. 来自需求
2. 接口定义：模块或子系统之间的通信接口
3. 领域模型

1. 技术选型
1. 开发语言
2. 开发工具
3. 技术框架、第三封类库
2. 文件划分
3. 编译关系

1. 硬件分布
1. 单板机
2. 单片机
3. 专用机
4. PC
5. 服务器
6. 拓扑结构
7. 络类型
8. 总线规范
2. 软件部署
1. 桌面软件安装
2. 烧写嵌入式系统
3. 部署web应用
3. 方案优化
1. 高性能（付出）
2. 可用性【持续可用性/高可用性】（付出）
3. 伸缩性（付出）
4. 经济性（节约）
5. 可行性（节约）
6. 易维护性（节约）

1. 技术选型
1. 进程
2. 线程
3. 中断服务程序（嵌入式应用的并发机制）
2. 控制流划分
3. 同步关系：资源争抢时需要加锁

1. 技术选型
1. 关系数据库
2. 非关系数据库
3. Flash
4. (分布式)文件
2. 存储格式
3. 数据分布

《软件架构设计》是2007年电子工业出版 出版，温昱编著的书籍。本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件架构设计教材，也可作为软件开发高级培训、软件开发管理培训的培训教材，更是第一线高级开发人员和开发管理人员的必备参考书。学习架构知识首先要提升看问题的高度，而且不能天马行空或者拿来主义，一定要学习方法论。思想和方法都已经告诉给大家了，附赠常用架构风格表：