目录
架构师到底是做什么的？
什么是软件架构？
在百度百科上的定义：
架构，又名软件架构，是有关软件整体结构与组件的抽象描述，⽤于指导⼤型软件系统各个方面的设计。
在 Wikipedia 上的定义：
Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.
ISO/IEC 42010:20072 中对架构的定义：
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
软件架构的本质
架构体现的是整体结构和组件之间的关系：
- 本质是为了管理复杂性。
- 本质就是对系统进行有序化重构，不断减少系统的 “熵”，使系统不断进化，以符合当前业务的发展，并可以快速扩展。
上述表达了架构的核心目的：
- 管理复杂性
- 效率最大化
以及架构的两个主要变化来源：
- 一个是以改善软件质量为目的的内在结构性变化；
- 另外一个是以满足客户需求为目的的外在功能性变化。
无论是何种变化，架构都是在不断的判断和取舍，在业务需求和系统实现之间做权衡，从而来应对未来变化的不确定性。
架构的过程，即：建模的过程
架构的过程其实就是建模的过程，即：模块的拆分和集成。
Linus 03 年在聊到拆分和集成时有一个很好的描述：
让我们认识到一种现象，把复杂系统拆分成模块，似乎并没有降低整个系统的复杂度。它降低的只是子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间，不得不进行交互，变得更加复杂。
可见，系统拆分就是实现一个架构的过程，基本出发点是为了效率，通过架构的合理拆分（无论是空间还是时间上的拆分），最终目的让效率最大化。
现实世界到软件世界的过程，是一个不断抽象的过程，即：不断的建立模型。
从现实世界到业务模型，从业务模型到概念模型，从概念模型到设计模型，通过不断的抽象去粗取精，形成对现实世界的层层抽象，所以架构的过程其实就是建模的过程。
百度百科定义：
建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。
《Thinking in UML》定义：
建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。
从上述两个定义上基本可以了解到建模就是抽象，对业务或现实世界的抽象，架构的过程是建模的过程。
业务建模
理解业务本身，需要对行业背景有深入的了解，最终才能够产出《业务核心流程图》和《业务功能模块图》。
系统建模
通过业务建模完成了从现实世界到业务模型的构建，在此基础上，如何通过抽象完成业务模型到设计模型的映射，这是系统建模要解决的问题。
系统建模一定是在业务建模的基础上，完成业务需求到系统模型之间的映射；这其中涉及业务功能到系统能力、业务流程到数据流程的映射；系统建模更强调职责、依赖、约束关系，用于指导研发的落地实现。
抽象能力
Haskell 语言的设计者之一 Paul Hudak 曾说过一句略带夸张的话：编程中最重要的三件事是：抽象，抽象，抽象。那么，什么是抽象？
百度百科定义：
从具体事物抽出、概括出它们共同的方面、本质属性与关系等，而将个别的、非本质的方面、属性与关系舍弃，这种思维过程，称为抽象。
抽象就是做减法和做除法。通过舍弃非本质和无关紧要的部分，着眼于问题的本质，去粗取精；通过透过现象看本质，发现不同事物之间的共同之处，异中求同，同类归并，也就是做除法。建模过程是共性抽象，通过不断的抽象达到某个状态为止。
Wikipedia 关于抽象的定义中有一个关于报纸的例子：
- 我的 5 月 18 日的《旧金山纪事报》
- 5 月 18 日的《旧金山纪事报》
- 《旧金山纪事报》
- 一份报纸
- 一个出版品
这五句话中，我们可以感受到抽象的层次，抽象层次越高，细节越少，普适性越强。
抽象纵向层次
再比如下图中关于网络模型的抽象，关于操作系统内核的抽象，我们可以明显的看到不同层次的抽象，就是过滤不同的信息，最终留下来的信息才是当前抽象层次所需要的信息。
从系统设计实现上来说，抽象层次越高，越接近设计，越远离实现，同时抽象的模型越不受细节的羁绊，稳定性越高，普适性越强，可重用性就越高。
那么，抽象的划分层次的依据是什么？原则又是什么？
依据：
- 以抽象角度分层（可能一层是多角度的聚合）。
- 面对变化分层（用层次隔离变化）。
原则：
- 公用的往下走。
- 个性的往上走。
- 下层可以独立于上层存在。
- 控制下层的变化。
抽象横向模块
我们还需要考虑的抽象的边界。如果说层次考虑的是纵向维度的表达（分层次），那么边界考虑的是横向维度的表达（分功能模块）。如何确定边界，一个总的原则是按照职责进行划分，这里的职责其实也就是分工。
一旦职责确定，在做建模分析时就不需要把整个业务大局放进来从头到尾去分析一遍，只需要考虑当前分工下的上游和下游即可，这样的信息量大大减少，自然的，面对的领域复杂度也会降低到一定程度。
抽象分界的依据就是要确定：
- 核心实体。
- 核心实体业务流程。
- 核心实体生命周期。
抽象的评估原则
高内聚，低耦合是评估一个抽象的基本原则。
- 内聚是一个模块内部各成分之间相关联程度的度量。
- 耦合是软件结构中各模块之间相互连接的一种度量。
抽象的方法论
抽象有两种方法，一种是自顶向下，另一种是自底向上。
- 业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程。
- 系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程。
下面这张图来自于《Thinking in UML》：
参考文档
《如何画好一张架构图？》