[架构之路-90]：《软件架构设计：程序员向架构师转型必备》-0-总结

前言

软件行业技术开发从业人员众多，但具备若干年开发经验的普通的开发人员往往面临个人发展的瓶颈，即如何从普通开发人员转型成高层次的系统架构师和技术管理人员。

想成为一名架构师，应当具备全面的知识体系?需要进行系统的学习和实践？

很多开发人员有往架构师转型的强烈意愿，但苦于找不到好的方法和路径。

今天分享的这份资料主要包含：

• 软件开发普通程序员向系统架构师转型的一些思路、方法和工程实践。

• 也包括转型过程中意识形态的转变、技术体系的掌握、系统工程学的拓展及各项软技能的提升等内容。

本书深入剖析成 为一名合格的架构师所需要的各项软、硬技能，重点对目前业界主流的架构师所需掌握的技术知识领域， 以及作为一名技术管理人员所需具备的技术管理能力 进行详细介绍，并结合一些典型的场景进行案例分析 ，从而帮助读者了解并掌握成为架构师所需的各种知识体系和实践技巧。

面向立志于转型成为架构师的后端服务开发人员。读者不需要有很深的技术水平，也不限于特定的开发语言，但熟悉Java EE常见技术并掌握一定系统设计基本概念将有助于好地理解书中的内容。同 时，本书也可以供具备不同技术体系的架构师同行参考，希望能给日常研发和管理工作带来启发和帮助。

整本书包括：

• 1.程序员向架构师转型的基本思路：剖析架构师角色，提供架构师的视图和视角及程序员向架构师成功转型的思路；

• 2.系统架构设计技术知识体系篇：介绍软件架构体系结构、领域驱动设计、分布式系统架构设计、构架实现技术体系等架构师所应具备的主要技术体系内容；

• 3.软件架构系统工程篇：介绍软件工程学、敏捷方法与实践、软件交付模型等架构师所应具备的系统方法论和相关工程实践；

• 4.架构师的软能力、思想、思维转变篇：包括架构师与外部环境、自身团队和转型所需的意识形态。

它山之石:读后感

本文以方法论为主，还不错，很全面，覆盖到架构师要了解的知识各方面。

结合实践讲述架构演进，也列举了主流的架构标准定义，适合实施层面参考。

架构设计的目的开宗明义提炼为:

• 为了最大程度降低系统复杂度

• 解决存在的共性和特殊问题。

这其实是从维护角度解释的，虽然不够深刻，但足够实用。

• 展现未来待实现系统的愿景

目录

导言

第1章 从程序员到架构师

1.1 软件业人才结构

1.1.1 金字塔型，还是橄榄型？

1.1.2 从程序员向架构师转型

1.2 本书价值

1.2.1 阅读路径1：架构设计入门

1.2.2 阅读路径2：领会大系统架构设计

1.2.3 阅读路径3：从需求到架构的全过程

1.2.4 阅读路径4：结合工作，解决实际问题

第1部分 基本概念篇

第2章 解析软件架构概念

2.1 软件架构概念的分类

2.1.1 组成派

2.1.2 决策派

2.1.3 软件架构概念大观

2.2 概念思想的解析

2.2.1 软件架构关注分割与交互

2.2.2 软件架构是一系列有层次的决策

2.2.3 系统、子系统、框架都可以有架构

2.3 实际应用（1）——团队对架构看法不一怎么办

2.3.1 结合手上的实际工作来理解架构的含义

2.3.2 这样理解“架构”对吗

2.3.3 工作中找答案：先看部分设计

2.3.4 工作中找答案：反观架构概念的体现

第3章 理解架构设计视图

3.1 软件架构为谁而设计

3.1.1 为用户而设计

3.1.2 为客户而设计

3.1.3 为开发人员而设计

3.1.4 为管理人员而设计

3.1.5 总结

3.2 理解架构设计视图

3.2.1 架构视图

3.2.2 一个直观的例子

3.2.3 多组涉众，多个视图

3.3 运用“逻辑视图+物理视图”设计架构

3.3.1 逻辑架构

3.3.2 物理架构

3.3.3 从“逻辑架构+物理架构”到设计实现

3.4 实际应用（2）——开发人员如何快速成长

3.4.1 开发人员应该多尝试设计

3.4.2 实验项目：案例背景、训练目标

3.4.3 逻辑架构设计（迭代1）

3.4.4 物理架构设计（迭代1）

3.4.5 逻辑架构设计（迭代2）

3.4.6 物理架构设计（迭代2）

第2部分 实践过程篇

第4章 架构设计过程

4.1 架构设计的实践脉络

4.1.1 洞察节奏：3个原则

4.1.2 掌握过程：6个步骤

4.2 架构设计的速查手册

4.2.1 需求分析

4.2.2 领域建模

4.2.3 确定关键需求

4.2.4 概念架构设计

4.2.5 细化架构设计

4.2.6 架构验证

第5章 需求分析

5.1 需求开发（上）——愿景分析

5.1.1 从概念化阶段说起

5.1.2 愿景

5.1.3 上下文图

5.1.4 愿景分析实践要领

5.2 需求开发（下）——需求分析

5.2.1 需求捕获vs.需求分析vs.系统分析

5.2.2 需求捕获及成果

5.2.3 需求分析及成果

5.2.4 系统分析及成果

5.3 掌握的需求全不全

5.3.1 二维需求观与ADMEMS矩阵

5.3.2 功能

5.3.3 质量

5.3.4 约束

5.4 从需求向设计转化的“密码”

5.4.1 “理性设计”还是“拍脑袋”

5.4.2 功能：职责协作链

5.4.3 质量：完善驱动力

5.4.4 约束：设计并不自由

5.5 实际应用（3）——PM Suite贯穿案例之需求分析

5.5.1 PM Suite案例背景介绍

5.5.2 第1步：明确系统目标

5.5.3 第2步：范围 + Feature + 上下文图

5.5.4 第3步：画用例图

5.5.5 第4步：写用例规约

5.5.6 插曲：需求启发与需求验证

5.5.7 插曲：非功能需求

5.5.8 《需求规格》与基于ADMEMS矩阵的需求评审

第6章 用例与需求

6.1 用例技术族

6.1.1 用例图

6.1.2 用例简述、用户故事

6.1.3 用例规约

6.1.4 用例实现、鲁棒图

6.1.5 4种技术的关系

6.2 用例技术族的应用场景

6.2.1 用例与需求分析

6.2.2 用例与需求文档

6.2.3 用例与需求变更

6.3 实际应用（4）——用例建模够不够？流程建模要不要

6.3.1 软件事业部的故事

6.3.2 小型方法：需求分析的三套实践论（上）

6.3.3 中型方法：需求分析的三套实践论（中）

6.3.4 大型方法：需求分析的三套实践论（下）

6.3.5 PM Suite应用一幕

第7章 领域建模

7.1 什么是领域模型

7.1.1 领域模型“是什么”

7.1.2 领域模型“什么样”

7.1.3 领域模型“为什么”

7.2 需求人员视角——促进用户沟通、解决分析瘫痪

7.2.1 领域建模与需求分析的关系

7.2.2 沟通不足

7.2.3 分析瘫痪

7.2.4 案例：多步领域建模，熟悉陌生领域

7.3 开发人员视角——破解“领域知识不足”死结

7.3.1 领域模型作为“理解领域的手段”

7.3.2 案例：从词汇表到领域模型

7.4 实际应用（5）——功能决定如何建模，模型决定功能扩展

7.4.1 案例：模型决定功能扩展

7.4.2 实践：功能决定如何建模

7.4.3 PM Suite领域建模实录（1）——类图

7.4.4 PM Suite领域建模实录（2）——状态图

7.4.5 PM Suite领域建模实录（3）——可扩展性

第8章 确定关键需求

8.1 众说纷纭——什么决定了架构

8.1.1 用例驱动论

8.1.2 质量决定论

8.1.3 经验决定论

8.2 真知灼见——关键需求决定架构

8.2.1 “目标错误”比“遗漏需求”更糟糕

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

8.3 付诸行动——如何确定关键需求

8.3.1 确定关键质量

8.3.2 确定关键功能

8.4 实际应用（6）——小系统与大系统的架构分水岭

8.4.1 架构师的“拿来主义”困惑

8.4.2 场景1：小型PMIS（项目型ISV背景）

8.4.3 场景2：大型PM Suite（产品型ISV背景）

8.4.4 场景3：多个自主产品组成的方案（例如IBM）

8.4.5 “拿来主义”虽好，但要合适才行

第9章 概念架构设计

9.1 概念架构是什么

9.1.1 概念架构是直指目标的设计思想、重大选择

9.1.2 案例1：汽车电子AUTOSAR——跨平台复用

9.1.3 案例2：腾讯QQvideo架构——高性能

9.1.4 案例3：微软MFC架构——简化开发

9.1.5 总结

9.2 概念架构设计概述

9.2.1 “关键需求”进，“概念架构”出

9.2.2 概念架构≠理想化架构

9.2.3 概念架构≠细化架构

9.3 左手功能——概念架构设计（上）

9.3.1 什么样的鸿沟，架什么样的桥

9.3.2 鲁棒图“是什么”

9.3.3 鲁棒图“画什么”

9.3.4 鲁棒图“怎么画”

9.4 右手质量——概念架构设计（下）

9.4.1 再谈什么样的鸿沟，架什么样的桥

9.4.2 场景思维

9.4.3 场景思维的工具

9.4.4 目标—场景—决策表应用举例

9.5 概念架构设计实践要领

9.5.1 要领1：功能需求与质量需求并重

9.5.2 要领2：概念架构设计的1个决定、4个选择

9.5.3 要领3：备选设计

9.6 实际应用（7）——PM Suite贯穿案例之概念架构设计

9.6.1 第1步：通过初步设计，探索架构风格和高层分割

9.6.2 第2步：选择架构风格，划分顶级子系统

9.6.3 第3步：开发技术、集成技术与二次开发技术的选型

9.6.4 第4步：评审3个备选架构，敲定概念架构方案

第10章 细化架构设计

10.1 从2视图方法到5视图方法

10.1.1 回顾：2视图方法

10.1.2 进阶：5视图方法

10.2 程序员向架构师转型的关键突破——学会系统思考

10.2.1 系统思考之“从需求到设计”

10.2.2 系统思考之“5个设计视图”

10.3 5视图方法实践——5个视图、15个设计任务

10.3.1 逻辑架构=模块划分+接口定义+领域模型

10.3.2 开发架构=技术选型+文件划分+编译关系

10.3.3 物理架构=硬件分布+软件部署+方案优化

10.3.4 运行架构=技术选型+控制流划分+同步关系

10.3.5 数据架构=技术选型+存储格式+数据分布

10.4 实际应用（8）——PM Suite贯穿案例之细化架构设计

10.4.1 PM Suite接下来的设计任务

10.4.2 客户端设计的相关说明

10.4.3 细化领域模型时应注意的两点

第11章 架构验证

11.1 原型技术

11.1.1 水平原型vs.垂直原型，抛弃原型vs.演进原型

11.1.2 水平抛弃原型

11.1.3 水平演进原型

11.1.4 垂直抛弃原型

11.1.5 垂直演进原型

11.2 架构验证

11.2.1 原型法

11.2.2 框架法

11.2.3 测试运行期质量，评审开发期质量

第3部分 模块划分专题

第12章 粗粒度“功能模块”划分

12.1 功能树

12.1.1 什么是功能树

12.1.2 功能分解≠结构分解

12.2 借助功能树，划分粗粒度“功能模块”

12.2.1 核心原理：从“功能组”到“功能模块”

12.2.2 第1步：获得功能树

12.2.3 第2步：评审功能树

12.2.4 第3步：粗粒度“功能模块”划分

12.3 实际应用（9）——对比MailProxy案例的4种模块划分设计

12.3.1 设计

12.3.2 设计的优点、缺点

12.4 实际应用（10）——做总体，要提交啥样的“子系统划分方案”

第13章 如何分层

13.1 分层架构

13.1.1 常见模式：展现层、业务层、数据层

13.1.2 案例一则

13.1.3 常见模式：UI层、SI层、PD层、DM层

13.1.4 案例一则

13.2 分层架构实践技巧

13.2.1 设计思想：分层架构的“封装外部交互”思想

13.2.2 实践技巧：设计分层架构，从上下文图开始

13.3 实际应用（11）——对比MailProxy案例的 4种模块划分设计

13.3.1 设计

13.3.2 设计的优点、缺点

第14章 用例驱动的模块划分过程

14.1 描述需求的序列图 vs. 描述设计的序列图

14.1.1 描述“内外对话” vs. 描述“内部协作”

14.1.2 《用例规约》这样描述“内外对话”

14.2 用例驱动的模块划分过程

14.2.1 核心原理：从用例到类，再到模块

14.2.2 第1步：实现用例需要哪些类

14.2.3 第2步：这些类应该划归哪些模块

14.3 实际应用（12）——对比MailProxy案例的 4种模块划分设计

14.3.1 设计

14.3.2 设计的优点、缺点

第15章 模块划分的4步骤方法——运用层、模块、功能 模块、用例驱动

15.1 像专家一样思考

15.1.1 自顶向下vs.自底向上，垂直切分vs.水平切分

15.1.2 横切竖割，并不矛盾

15.2 模块划分的4步骤方法——EDD方法

15.2.1 封装驱动设计的4个步骤

15.2.2 细粒度模块的划分技巧

15.3 实际应用（13）——对比MailProxy案例的4种模块划分设计

15.3.1 设计

15.3.2 设计的优点、缺点

写在最后：

一个程序员，第一次看到团队架构师熟练划分模块，会不免地心生敬礼，架构是软件的灵魂，而架构师则是背后的”造物主“。

架构师要求：

首先是博学，对于可靠性（容错、冷备、热备、集群部署）、吞吐量、安全性（认证技术、密码学、基本网络攻防）等有清晰的理解和实践经验。

其次是实践，这些知识更多是从实践中获得，很难直接从教科书上获得。

最后是机会（运气），没有锻炼机会，纵有冲天之志，非运气不能自拔。

作者感悟

无论是架构只是的完备性，还是从语言的表达效果，这本书都是值得推荐的。