第113篇
极客时间《许式伟的架构课》课程笔记。
基础架构与业务架构
桌面开发
- 基础架构就是做技术选型：选择要支持的操作系统、选择编程语言、选择技术框架、选择第三方库
- 架构师之间的差距，更大的是体现在其对待基础架构的态度和能力构建上
- 业务架构就是业务系统的分解能力：分解领域问题，即分解这个领域的用户群面临的普遍需求
- 没有需求分析，就没有业务架构。在业务架构过程中，需求分析至少应该花费三分之一以上的精力
- 系统的概要设计，简称系统设计：就是 “对系统进行分解” 的能力，明确子系统的职责边界和接口协议，把整个系统的大框架搭起来
分解系统的评判依据
- 功能的使用界面（或者接口），应尽可能符合业务需求对它的自然预期
- 功能的实现要高内聚，功能与功能质检的耦合尽可能低
接口要自然体现业务需求
- 函数的使用界面是函数原型，包含函数名、输入参数列表及输出结果列表3部分
- 类的使用界面是类的公开属性和方法，包含类型名、公开属性列表及公开方法列表
- 模块的使用界面需要看模块类型，典型模块类型有包（package）、动态库（dynamic library）、可执行程序（application）
- 包和动态库都是代码的一种发布形态，但标准制定方不同，包一般由编程语言定义，而动态库一般是操作系统定义，可以跨语言
- 常见可执行程序：网络服务程序（service）、命令行程序（command line application）、桌面程序（GUI application）
- 网络服务程序的使用界面是网络协议
- 命令行程序的使用界面包括命令行、标准输入、标准输出
- 桌面程序的使用界面就是用户的操作方式，最重要的是交互范式，即用户如何完成功能的业务流程的定义
- 子系统是一个逻辑概念，物理上可能对应一个模块，也可能是多个模块，可以理解为一个逻辑上的大模块
- 类和函数是从语言级的函数调用来完成业务，网络服务程序是通过网络 RPC 请求来完成业务，桌面程序是通过用户交互来完成业务
功能实现准则：高内聚低耦合
- 高内聚就是一个功能的代码应该尽可能写在一起，而不是散落在各处
- 高内聚的好处：多大的团队协作都会很顺畅，代码提交不会发生冲突
- 低耦合就是实现某个功能所依赖的外部环境少，易于构建
- 功能实现的两种外部依赖：对业务无关的基础组件依赖、对底层业务模块的依赖
- 对底层业务模块的依赖少耦合低的表现：对底层业务的依赖是“通用”的，尽量不要出现让底层业务模块专门为我定制接口；依赖的业务接口个数少，调用频次低
如何做系统分解？
- 系统分解是一个领域性的问题，它依赖于对用户需求的理解，并不存在放之四海皆可用的办法
- 系统分解首先要从需求归纳触发，把用户需求分析清楚，把需求功能点涉及的数据（对象）、操作接口理清楚，并归纳整理
- 系统概要设计阶段一般以子系统为维度阐述系统各个角色之间的关系，这个阶段的核心意图并不是确定系统完整的模块列表，而是整个系统如何被有效地串联起来
- 为了降低风险，系统的概要设计阶段也应该有代码产出。目的1：系统的初始框架代码。目的2：原型性的代码来验证
- 代码即文档。代码是理解一致性更强的文档
再谈MVC
- 桌面程序系统分解的套路就是 MVC 架构，框架结构都是基于事件分派做输入，GDI 做界面呈现
- 需求分析要分清需求的稳定点和变化点。稳定点是系统的核心能力，而变化点则需要做好开放性设计
- 最底层一般以类和函数的形态来组织业务的核心逻辑，这就是 Model 层。 Model 层不只是核心逻辑稳定，IO 和网络子系统也都很稳定
- 用户交互这个变化点，主要体现在两个方面。一方面是屏幕尺寸导致的变化，另一方面则是交互的变化
- View 层主要承担了界面呈现的工作，Controller 层主要承担的是交互。具体来说就是响应用户的输入事件，把用户的操作转化为对 Model 层的业务请求
- Model 层是一个整体，负责的是业务的核心逻辑。View 层也是一个整体，但在不同的屏幕尺寸和平台可能有不同的实现，但数量不会太多。Controller 层并不是一个整体，它是以插件化的形式存在，不同 Controlller 非常独立
