最近闲了，看了几次李运华关于架构的视频，不尽再次反问架构是什么？架构师的职责是什么？
对于这两个问题，之前也总结过一篇《架构和架构师》，再结合他的专栏文章和视频，补充一下
架构
李运华给架构的定义：软件架构指软件系统的顶层结构，缩句成架构指结构，而结构的修饰语蕴含了太多东西，抽象不够直白
这个定义里面蕴含了作者介绍的系统和子系统、模块与组件、框架与架构三组常见的概念
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”
软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。
软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
从逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理的角度来拆分系统后，得到的单元就是“组件”。
划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。其实，“组件”的英文 component 也可翻译成中文的“零件”一词，“零件”更容易理解一些，“零件”是一个物理的概念，并且具备“独立且可替换”的特点。
软件框架（Software framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品
软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述
这么多的概念，在不理解的情况下，最多能记忆一小时吧，其实就算是理解了，最多也就记忆一天。因为这些概念比较虚，离我们具体coding有点远，但学习新知识又都是从定义起始，定义不理解时，就实践，再回看定义，可架构太大了，短时间没能力也没条件去架构设计
而且这定义可是一位阿里P9级别多年经验总结归纳出来的，得行多少路，抽象了多少回，才有的认知，所以我也不打算靠记忆了，不过对于模块和组件的认知很独到
虽然架构定义众家纷说，但对于如何描述架构还是有共识的，那就是“4+1视图”，在《架构和架构师》也描述了，也就是说架构的确需要从各角度观察和考虑
想来还是喜欢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.
这里定义了架构的三要素：
- 职责明确的模块或者组件
- 组件间明确的关联关系
- 约束和指导原则
即架构是一种结构，是由组件（Components）+ 组件之间的关系 + 指导原则组成的
在《code review》中也提了，万事要以降低代码复杂度为大计，先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后Review完成的代码；到了架构设计更是得如此，落地到代码层面，也就是要解决代码要如何被组织的问题，以业务为核心，解耦外部依赖，分离业务复杂度和技术复杂度
架构师
架构说清楚了，那架构师呢？在《架构和架构师》中，也说了
【优秀程序员的价值,不在于其所掌握的几招屠龙之术,而是在细节中见真著】，那么架构师则不仅要有屠龙刀，还得有绣花针
但如何拥有屠龙刀和绣花针呢？架构师在国内，大多时候可能不是个岗位，而是个角色。大厂还有架构师一说，小厂难得有专职架构师，所以架构师职能还得多多取经大牛，学习一下大牛
架构师能力模型
这三部分好似是任何一个职业的三条腿，要像走向人生巅峰迎娶白富美，这三条腿都得硬，越往上走，尤其管理和业务
技术只是技术人的最基本敲门砖，初级阶段以技术为重，往上走时，重点就得向后偏移，不能一直安静地码代码
架构设计过程
这个过程，回顾最近几个系统设计的确是这样的
- 业务方提出一个业务，刚开始可能只是个目标，轮廓
- 与业务方、产品不停的交流，交流得越深入，需求就越明确
- 理解业务并明确需求后，划分模块，不管是传统画ER图，还是4色建模，找出实体以及他们的关系
- 模块确定后，就是再深入细节，模块内部的业务流程，模块之间的交互
- 最后整理，确定技术选型，输出设计方案
之后，在架构落地过程中，随着业务进化，不停地演化架构，这些像上面说的宏观面的屠龙刀，绣花针就体现在细节，有时细节决定成败，架构师需要去识别哪些细节会影响到架构，以防后面不停地打补丁
