Architecture Concepts¶

Complexity¶

计算机世界的本质¶

• Maybe you've heard that the computer world is a giant construction of abstractions. 计算机世界是一个由抽象组成的巨大结构体。
• We simply wrap things and produce new tools over and over again. 我们无非是重复着包装东西和生产新工具。

当我们在编程，我们在干什么？¶

• “The programming is all about managing complexity.” “编程是对复杂度的管理。”

什么叫复杂度？¶

• 本质复杂度（Essential complexity ）

  • Essential complexity is just the nature of the beast you’re trying to tame. 本质复杂度是解决问题时固有的最小复杂度。
  • 与你用什么样的工具、经验是否丰富、架构好不好等都无关

• 偶然复杂度（Accidental complexity）

  • 偶然复杂度是实际开发过程中引入的复杂度。
  • 开发者要尽量减少偶然复杂度；程序猿的身价在此分化。

  • 架构的意义

    • 把犯错的决策，抛给更有经验的架构师
    • 加大做出错误决策的难度，增加正确决策的可能性，从而使我们 fall into the pit of success.

架构¶

架构的定义¶

• 百度百科

  • 架构，又名软件架构，是有关软件整体结构与组件的抽象描述，⽤于指导⼤型软件系统各个方面的设计。

• Wikipedia

  • Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.

• ISO/IEC 标准

  • 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.

  • Architecture = Structure of Components + Relationships + Principles & Guidelines

架构的本质¶

• 架构的本质是为了管理复杂性。
• 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
• 架构的本质就是对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。

架构的过程：建模¶

• 架构的过程其实就是建模的过程。
• 建模的本质是类比。
• 对现实世界的抽象 -> 业务模型 -> 概念模型 -> 设计模型

• 建模的定义

  • 百度百科

    • 建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

  • 《Thinking in UML》

    • 建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。

• 模是什么？如何建？

  • 业务建模

    • 1) “把书读厚”

      • 大量的信息输入，同时探求可能性。
      • 未必照顾到所有细节，但力求覆盖整体内容。

    • 2) “把书读薄”

      • 归类汇总，形成大图。
      • 建立“大局观”，梳理自己的逻辑主线，如横纵式，或者矩阵式；
      • 思考一：谁？用什么样的服务/功能/能力？解决什么样的问题？ 得出：参与者角色、系统能力、交互关系。
      • 思考二：边界是什么？输入输出是什么？ 得出：角色 -> 主流程 -> 分支流程

    • 3) 逻辑对照

      • 确保理解和分析的正确性。
      • 一个闭环封装的过程。
      • 将一些逻辑细节、关键流程，逐一放到大图里去对照验证；确保业务抽象能够覆盖所有已知的业务用例，以及支持可能的业务场景。

    • 总结

      • 业务架构图的核心目的是统一共识、减少沟通成本，无论是项目中的哪个角色大家都能讲一样的话，描述一样的事情。
      • 这实际上是建立对话能力和对话语境。

  • 系统建模

    • 理解

      • 业务建模，完成业务需求到系统模型之间的映射；涉及业务功能到系统能力、业务流程到数据流程的映射。
      • 系统建模 更强调职责、依赖、约束关系，用于指导研发的落地实现。

    • 方法参考

      • 1）“剥洋葱”

        • 从业务建模的“大局观”去按职责分工拆解成多个子系统、多个子模块、然后在模块能进行细分，层层剥解。

      • 2）核心实体抽取

        • 对象的分析方法

          • 实体（Entity）：客观存在并可相互区别的事物称之为实体。实体可以是具体的人、事、物,也可以是抽象的概念或联系。
          • 实体对象的抽取：独立、可抽象、有层次性、在单个层次上又具备原子性。

        • 用例分析的方法

          • 提取关键词，不同的关键词可能表达了实体、关系、属性等等内容。
          • 结构类比（实体）：名词，以「主语」和「宾语」为主；
          • 属性类比：形容词，存在于「定语」和「状语」中；
          • 关系类比：动词 & 介词词（存在于「谓语」，「状语」，「定语」）；
          • 领域模型：对用例的补充，细化，对名词进行定义；

        • 问题分析的方法

          • 寻找问题的主体，然后分析主体的生命周期，进而通过区分生命周期里的关键活动来聚焦主体的关键属性和关键关系。

      • 3）自己讲给自己 (self-explain)

        • 在所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己。
        • 请注意这里是“分别套入”，在当前的设计层次下一个场景验证完再去验证下一个场景，找出阻塞的、模糊的点，重新梳理再优化设计。

关于抽象¶

• 抽象的意义

  • Haskell 语言的设计者 Paul Hudak 曾说过：编程中最重要的三件事是：抽象，抽象，抽象。

• 抽象的定义

  • 百度百科定义

    • 从具体事物抽出、概括出它们共同的方面、本质属性与关系等，而将个别的、非本质的方面、属性与关系舍弃，这种思维过程，称为抽象。

  • 抽象就是做减法和做除法。

    • 通过舍弃非本质和无关紧要的部分，着眼于问题的本质，去粗取精；
    • 通过透过现象看本质，发现不同事物之间的共同之处，异中求同，同类归并，也就是做除法。

• 抽象的角度

  • 抽象角度即分类的角度；
  • 抽象的角度就是建模的方向和目的（“屁股决定脑袋”）。
  • 模是在确定的抽象角度下的业务映射。

• 抽象的层次

  • 抽象层次越高，细节越少，普适性越强。

  • 方法

    • 以抽象角度分层（可能一层是多角度的聚合）
    • 面对变化分层（用层次隔离变化）

  • 原则

    • 公用的往下走
    • 个性的往上走
    • 下层可以独立于上层存在
    • 控制下层的变化

• 抽象的边界

  • 层次考虑的是纵向维度的表达，边界考虑的是横向维度的表达。
  • 边界的定义：边界是在确定抽象角度下，通过寻找 核心的业务活动，抽取 核心实体，进一步确定 实体核心生命周期 的结果。
  • 寻找生命周期的过程，就是发现内聚的过程；将所有关于生命周期的业务活动累积，就可以提升领域或模块的内聚性。

• 抽象的评估

  • 原则

    • “高内聚，低耦合”

  • 方法

    • 每次从一个角度来切分，然后换多个角度来审视
    • 通过组合、拆分来精化、优化模型与设计（抽象的结果）

    • 关键的审视点

      • 耦合性：减少模块间通信量
      • 变化的隔离性：减少信息依赖，建隔离层、虚拟层
      • 内聚性：功能单一化

• 抽象的方法论

  • 抽象有两种方法，一种是自顶向下，另一种是自底向上
  • 业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程
  • 系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程
  • 但不绝对，自上而下和自下而上，往往在过程中是随意切换的

架构图¶

架构图 = 架构 + 图¶

• 架构是什么？图是什么？

架构图 = 架构的表达 = 表达架构的图¶

• 什么是架构？要表达的到底是什么？
• 如何画好一张架构图？

• 要表达的是什么？

  • 关注业务架构和系统架构

画架构图是为了什么？¶

• 解决沟通障碍：达成共识、减少歧义。
• 提升协作效率：团队内部和团队之间的协作、沟通、愿景和指导。

怎么画？¶

• 分类

  • 抽象层次：业务全域 —> 子域 —> 模块 —> 子模块—> 包 —> 类 —> 方法
  • 较低层次的抽象：应用内部包图、类图；某个领域：实体图、时序图、状态图、用例图等等。
  • 较高层次的抽象：具有一定的复杂性，比如微服务架构，系统间的交互图，领域/子领域架构图，整个系统架构图等等。

• 构图

  • 考虑内容术语一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题。

架构师¶

工作¶

• 功能分析（画框框）
• 技术选型（挑工具）
• 架构设计（高内聚/低耦合）

建议¶

• 快速学习
• 不要屁股决定脑袋（位置决定想法）
• 提升思考能力和对于技术原理或本质的理解

Frontend¶

现状¶

• 已不拘泥于页面展示 && 通过全栈来闭环产品
• 前端已经有能力透过业务深入产业，进而影响商业结果。
• 技术革新 -> 突破自身边界 -> 重定义价值

技术栈¶

• 纯表现层

  • 用户体验、布局、特效、CSS各种奇技淫巧等。

• 应用实现层

  • 拿着别人设计好的框架、工具其实现具体应用逻辑。考察：开发效率。

• 应用架构层

  • 技术选项、开发底层框架、制定开发规范、设计应用结构。考察：编译原理、算法、数据结构。

• 基础设施层

  • 自动化构建、部署，测试，加载方案，性能优化，代码质量等。考察：软件工程能力。

• 理念层

  • 通过借鉴整个计算机体系中其他领域的思想，从根本上改进前端的开发范式。

Serverless¶

• 不如说 Serverless 是一种理想的工作模式，是一种专注于业务价值的思考。
• 单纯的 通过函数进行业务交付
• 不必关心解决业务问题之外的事情(如基础设施)