软件架构设计：程序员向架构师转型必备思维导图

这是一篇关于软件架构设计：程序员向架构师转型必备的思维导图。想知道程序员向架构师转型必备技能吗？快来吧。

软件架构设计： 程序员向架构师转型必备

第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：结合工作，解决实际问题

第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.3运用“逻辑视图+物理视图”设计架构

3.3.1逻辑架构

3-3.2物理架构

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

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

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

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

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

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

第4章 架构设计过程

4.1建筑设计的实践脉络

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.2需求开发（下）——需求分析

5.3掌握的需求全部全

5.3.1 二维需求观与ADMEMS矩阵

5.3.2功能

5.3.3质量

5.3.4 约束

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

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

第8章 确定关键需求

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

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

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

第6章 用例与需求

第7章 领域建模

领域建模处在“业务流程”和“系统流程”之间， 如果缺失了领域建模，会直接把业务流程实 现成系统流程。而这也是开发人员经常会遇 到的问题，其中会产生许多问题：

7.1什么是领域模型？

7.1.1领域模型“是什么” What

《软件架构设计》15.2 为什么要“领域驱动” 领域就是现实世界的业务，是复杂多变的， 我们看到的只是现象；而领域模型就是要 找到这些现象背后不变的部分，也就是本质。 找到了“本质”，也就是“变化”背后的“不变性”， 也就找到了“问题”的“答案”。

具体到领域驱动设计方法论，其引入了 一系列概念：实体、值对象、聚合根、 领域事件、Specification。就像任何一 门语言，最基本的是单词；同样的，领域 驱动设计的这些概念就是领域模型这门 建模语言的单词。有了单词，可以组装成 句子、段落和文章。

这些概念给了我们一系列的分析工具，帮助我们分析出“领域”现象背后的“本质”： ○你的领域里面有哪些核心实体？ ○这些核心实体又由哪些子核心实体组成？ ○核心实体的生命周期（状态迁移）是什么样的？ ○核心实体之间是什么关系？除了核心实体， 是否还有某些核心的事件、业务规则和算法？

领域模型如何描述

《软件架构设计》15.2 为什么要“领域驱动”

为什么要领域驱动？

7.1.1领域模型“什么样” How

就UML而言，领域模型最常采用下面两种图表示： 一类图，二状态图。

举例，图7-1银行领域模型的凭证相关部分

7.1.1领域模型“为什么” Why

图7-3总结了领域模型 对整个软件开发活动 的重要作用——涉及5点

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

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

7.2.2 沟通不足

第1个困难：用户的参与不够， 造成需求分析成果中假设的成分太多。

7.2.3 分析瘫痪

第2个困难：问题领域太复杂时， 需求分析的开展会遇到困难。

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

领域知识的核心是领域概念之间的关系，很多时候 开发人员对单个概念还是比较清楚的，但一旦涉及 领域概念之间的“对应”关系、“包含”关系、“如果…… 则……”关系时开发人员就比较容易发憷“领域知识不足”。

因此破解领域知识不足死结的关键是“理顺概念关系，搞清业务规则”。 这恰是领域模型的“强项”，通过对复杂的领域进行“概念抽象”和“关系 抽象”建立模型，获得对领域知识总体上的把握，就不会掉入杂乱无章 的概念“堆”里了。

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

第15章 模块划分的4步骤方法 ——应用层、模块

15.1 像专家一样思考

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

能不能用一幅图把第12～14章 的内容进行概括，对比清楚？

图15-1 模块划 分技能 的4种 思路

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 设计的优点、缺点

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

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

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

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

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

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

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

【技术1】运用鲁棒图，发现实现用例需要哪些类

【技术2】运用序列图，明确类之间的交互关系

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

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

14.3.1 设计

14.3.2 设计的优点、缺点

第13章 如何分层？

13.1 分层架构

13.2 分层架构实践技巧

子主题

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

从图15-1复杂业务软件开发的几个阶段， 可以看出领域模型处在“业务流程”和 “系统流程”之间

第一，业务流程是粗粒度的，给非开发人员 （产品人员、运营人员、用户等）来看的， 而系统流程需要更细化，比如业务流程说某 个“数据”从系统A流向系统B，但并没有说这 个“数据”有哪些字段？这种流向是“推模式”还 是“拉模式”？是用消息中间件实现，还是用 RPC或者HTTP调用？

站在业务人员的角度，不关注这些技术问题， 但技术人员需要很关注，因为这些问题会影响 系统的可维护性、性能、稳定性等。

15.3 “业务 流程” 不等于 “系统 流程”

Part III 模块划分专题

第11章 架构验证

第10章 细化架构设计

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接下来的设计任务

例如，将PM S uite系统、 需求管理系统、 测试管理系统、 OA 管理系统、 HR 管理系统等一同考虑在内，

图10-16 PM Suite的物理架构视图

10.4.2 客户端设计的相关说明

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

图10-19 领域模型与“领域建模”、 “领域模型细化”的关系

第9章 概念架构设计

9.1概念架构是什么

概念架构设计概述

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

图9-11研究用例，进行鲁棒图建模

图9-12 鲁棒图的桥梁作用(图片来源： 《UML用例驱动对象建模》)

图9-13 鲁棒图三元素的具体化， 以及与MVC的对比

MVC猫头鹰

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

图9-19 以场景为“跳板”的非功能目标设计思维

图9-24设计网上书店系统——更新设计

图9-25 概念架构设计要明确的是“1个决定，4个选择”

9.5概念架构设计实践要领

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