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