《软件架构设计》读书笔记

一、什么是架构？

从书中可以看到两个观点：

1. 架构=组件 +  交互

2.架构= 重要决策集

我更倾向于第一个观点，而用第二个观点提醒自己系统概要设计、详细设计等架构落地时候是否设计原则遵守了架构原则。

二、子系统、框架和架构

在解释这三个概念的时候，我想还要再加上要给概念：平台。好吧，分裂吧，程序员们。

子系统：这个概念最为简单，就是一个系统的细分，它具有系统的完整特性，要应用框架，要遵循架构设计。它的出现，是为了松耦合，分离关注点。

框架：我接受一种比较抽象的说法，框架是一个可实例化部分完成的系统或者子系统，它为一组系统或子系统提供定义了架构，并提供了构造系统的基本构造块。或者，我们可以有一种更为程序员接受的说法：框架是一组可以相互协作的类，形成类似软件的可复用设计。

平台：这个悲剧了，解释不清楚。但是，大概来讲就是平台是可以独立提供基础支撑的软件系统，用于在上面开发系统（鄙视这段话吧）。

有一个问题可以思索：当设计框架的时候，如何设计扩展点？

三、架构的作用

1. 上承业务目标

2. 下接技术决策

3. 控制复杂度：这个有必要说一下，架构本质还是解决问题复杂度的学问，对业务进行合理的划分，合理规划系统组件结构，使得每个项目的参与人员都能在全局中找到自己应解决的问题，从而解决整个问题的复杂性。

4. 组织开发。利用架构的划分，组织开发力量。

5. 迭代交付产品。

6. 提高质量和可维护性。

四、软件架构的视图

五、架构视图的5视图法

1. 逻辑架构：逻辑架构关注功能实现。可能包括：逻辑层、功能模块等。

2,. 开发架构：包括技术选型，逻辑层、功能模块使用的技术和框架、类库；每个程序模块的项目组织结构、包结构等。

3. 运行架构：运行期间的进程、线程、对象等运行时概念；以及通信、并发、同步等问题，提供一个稳定的运行系统。

4. 物理架构：包括机器部署、物理节点等。

5. 数据架构：数据的存储方案，数据层，数据在系统间的传递、复制、同步、分发等。

六、概念性架构到实际架构

这一章解释了一个很好的问题：web应用、mysql和oracle的概念性架构是相同的，而实际架构差的很多，具体一点说就是MVC、分层、组件化等这些都是概念性架构，它制定了系统最初的设计，是战略而不是战术，具有策略性但是不全面。所以，当你决定系统用MVC去开发的时候，这并不是一个架构。

七、如何进行成功的架构设计

1. 全面认识需求

2. 关键需求决定架构

3. 多视图探寻架构

4. 及早验证架构

八、架构要设计到什么程度

1. 避免高来高去的架构

2. 缺乏重要视图对团队成员没有指导作用

3. 浅尝辄止，不够深入

九、架构设计的过程

十、需求分析

运行期质量：性能（performance）、安全性（Security）、易用性（Usability）、可持续性（Availability）、可伸缩性（Scalability）、互操作性（Interoperability）

可靠性（Reliability）、鲁棒性（Robustness）

开发期质量：易理解性（Understandability）、可扩展性（Extensibility）、可重用性（Reusability）、可测试性（Testability）、可维护性（Maintainability）、可移植性（Portability）

十一、用例技术。（可以参考UML）

十二、领域模型

第一次接触到领域模型是2009年的一个项目，不过这个没给我留下好印象更，貌似这玩意也不适合互联网应用，更适合传统软件。

十三、确定关键需求（略）。

十四、概念性加固（略）。

十五、质量性属性。

十六、细化架构。

十七、如何验证架构

1.原型法

2.框架法

十八——二十五

性能的模式:

1. 替代路由。

2. 弹性时间。

3. 批处理。

4. 耦合。

5. 快速通道。

6. 弱化周期性功能。

7. 重要任务优先。