读书笔记@软件架构设计

这本书跟《一线架构师指南》相比，同一个作者写的、很多是重复的内容。但有鉴于这是20年前的一本书，在咨询技术类里面质量有一般吧。

2018/8/11、早起送妈、地铁上

 

＃什么是架构＃

书中提到两派观点，一派是组成派，一派是决策派。组成派的观点是软件架构是组件和组件间的关系。组件属于结构、关系属于行为，也算软件里面比较经典的划分了。另一个决策派，不仅包括软件架构的组成，还包括在软件工程整个生命周期里面做的那些决策，包括需求分析，系统分析，概要设计等过程。

个人更偏向于决策派。或者叫做软件开发过程中的一些重大系统决策。

首先需要定义软件开发过程，按照togaf的一个定义包含：预备阶段，架构愿景，业务架构，IT架构（应用架构+数据架构)，技术架构，解决方案，迁移/实施计划，变更管理。

软件架构，包括含方法、理论、工具，以及研发过程中系统决策的各种交付物。

 

＃架构由什么驱动＃

软件架构由什么驱动？现在流行的是ddd、领域模型驱动，过去火过的有uml、建模驱动，有usecase、需求用例驱动。

书中提及：架构=功能需求+非功能需求+质量约束。大抵是对的，除了以上内容，还要有方法论指导怎么思考、怎么做。架构绝对不是由静态的、死的模型驱动，而是由活的、动态的用例驱动。

建筑工程的设计最基本的有两个图：建筑平面图，建筑施工图。建筑平面图用于标注空间、尺寸的关系。建筑施工图用以指导布线、水电这些如何施工。真正一个客户的需求，可能包括北欧风的审美需求，也包括两个小孩子打闹的功能需求。客户需求和平面图之间的黑色地带，才真正体现着建筑师的思想和水平。

软件架构的核心跟建筑架构类似。一方面在描绘业务组件及协作关系（平面图），另一方面是要真正去满足好业务需求（客户住宅需求）。

软件开发是一个迭代的过程，需求在迭代、架构也在迭代。这是跟建筑学不一样，软件工程的客户需求不仅持续不断、而且极有可能不连贯，导致软件架构的稳定性要受到很大挑战。

有变的地方就会有不变之处。如果软件架构没有任何的稳定性，那也就不需要什么设计了。不变的地方，就是整个架构的核心。

软件架构由一些抽象程度高的、关键核心需求所驱动。真正关键核心的需求应该非常少，也是系统的核心竞争力。这些关键核心的需求，不常变化、又做了足够抽象，稳定性非常好。

 

＃架构交付物＃

本书提及概念架构，用于需求分析和系统设计之间的中间过程，着重提及了鲁棒图。

鲁棒图包含三个元素，边界节点、实体节点，控制节点。连接它们的箭头代表逻辑顺序关系。鲁棒图非常优秀的把用户角色、系统边界、领域实体、核心功能、动态交互关系等，都简单清晰的呈现出来了。

鲁棒图和用例图的区别在于，把每个用例的内部结构都画出来了；和交互图的区别在于，省略了交互图的很多细节、比交互图范围更大，可以同时绘制多个场景。

在某种意义上，鲁棒图已经很好的代表了黑色地带的一个交付物。

当然还有老牌的4+1 view。想说的是，在每一个阶段的视角、我们都可以用4+1。不同的阶段会有不同的4+1。4+1不是对应5个研发阶段的1个视图，而是1个研发阶段的5个视图。