架构的具体内容

对于一个架构师而言, 其架构工作的内容大体分为两块, 一块是基础架构, 一块是业务架构

基础架构, 简单的说就是做技术选型. 选择要支持的操作系统, 选择编程语言, 选择技术框架, 选择第三方库, 这些都可以归结为基础架构方面的工作

基础架构的能力, 考验的是选择能力. 背后靠的是技术前瞻性和判断力. 这并不简单. 大部分架构师往往更容易把关注点放到业务架构上, 但实际上基础架构的影响面更广, 选错的产生代价更高

架构师之间的差距, 更大的是体现在其对待基础架构的态度和能力构建上, 真正牛的架构师, 一定会无比重视团队的技术选型, 无比重视基础平台的建设. 阿里提倡的 “大中台, 小前台” , 本质上也是在提倡基础平台建设, 以此不断降低业务开发的成本, 提升企业的创新能力.

业务架构, 简单的来说就是业务系统的分解能力. 基础架构其实也是对业务系统的分解, 只不过分解出了与业务属性几乎无关的部分, 形成领域无关的基础设施. 而业务架构更多的是分解领域问题.

一旦我们谈业务架构, 就避不开领域问题的理解. 所谓领域问题, 谈的是这个领域的用户群面临的普遍需求. 所以我们需要对用户的需求进行分析

我们已经进行过需求分析, 在业务架构过程中, 需求分析至少应该花费三分之一以上的精力

需求分析

系统的概要设计

简称系统设计 简单来说就是 对系统进行分解的能力. 这个阶段核心要干的事情,就是明确子系统的职责边界和接口协议, 把整个系统的大框架搭起来.

那么怎么分解系统?

最朴素的判断依据, 是这样两个核心的点:

  • 功能的使用界面(或者叫接口) , 应该尽可能符合业务需求对它的自然预期
  • 功能的实现要高内聚, 功能与功能之间的耦合尽可能低

在软件系统中有多个层次的组织单元: 子系统, 模块, 类, 方法/函数. 子系统如何分解模块?模块如何分解到更具体的类或函数? 每一层的分解方式, 都遵循相同的套路. 也就是分解系统的方法论.

接口要自然提现业务需求

使用界面

函数

对于函数, 它的使用界面就是函数原型

  1. package packageName
  3. func FuncName(
  4.     arg1 ArgType1, ... , argN argTypN
  5. )(ret 1 RetType1, ... , retM RetTypeM)

它包含三部分信息.

  • 函数名. 严谨来说是包含该函数所在的名字空间的函数名全称, 比如上例是 packageName.FuncName
  • 输入参数列表. 每个参数包含参数名和参数类型
  • 输出结果列表. 每个输出结果包含结果名和结果类型. 当然, 很多语言的函数是单返回值的, 也就是输出结果只有一个. 这种情况下输出结果没有名称, 只有一个结果类型, 也叫返回值类型.

类

对于类, 它的使用界面是类的公开属性和方法

  1. package packageName
  3. type ClassName struct {
  4.   Prop1 PropType1
  5.   ...
  6.   PropK PropTypeK
  7. }
  9. func (receiver *ClassName) MethodName1(
  10.    arg11 ArgType11, ..., arg1N1 ArgType1N1
  11.   ) (ret11 RetType11, ..., ret1M1 RetType1M1)
  13. ...
  15. func (receiver *ClassName) MethodNameL(
  16.    argL1 ArgTypeL1, ..., argLNL ArgTypeLNL
  17.   ) (retL1 RetTypeL1, ..., retLML RetTypeLML)

它包含以下内容

  • 类型名. 严谨来说是包含该类型所在名字空间的类型名全称, 比如上例是 packagName.ClassName
  • 公开属性列表. 每个属性包含属性名和属性类型. go语言对属性的支持比较有限, 直接基于类型的成员变量来表达. 而其他语言, 对属性的支持比较高级 运行设定 get/set 这样就能够做到 只读,只写,读写三种属性
  • 公开方法列表

对于模块, 它的使用界面比较多样, 需要看模块类型. 典型的模块类型有这样一些:

  • 包(package) . 一些语言中也叫静态库(static libray)
  • 动态库(dynamic library) . 在go语言中有个特殊的名称叫插件(plugin)
  • 可执行程序(application)

可执行程序

对于可执行程序(application) , 又要分多种情况. 最常见的可执行程序有这么几类:

  • 网络服务程序(service)
  • 命令行程序(command line application)
  • 桌面程序(GUI application)

网络服务程序

对于网络服务程序(service), 它的使用界面是网络协议. 大致如下

系统的概要设计 - 图1

命令行程序

对于命令行程序(command line application) , 它的使用界面包括:

  • 命令行, 包括: 命令名称, 开关列表, 参数列表. 例如: CommandName-Switch1 … -SwitchN Arg1 … ArgM
  • 标准输入(stdin)
  • 标准输出(stdout)

桌面程序

对于桌面程序(GUI application) , 它的使用界面就是用户的操作方式. 桌面程序的界面外观当然是重要的, 但不是最重要的. 最重要的交互范式, 即用户如何完成功能的业务流程定义. 为什么我们需要专门映入产品经理这样的角色来定义产品, 正是应为使用界面的重要性

以上这些组织都物理上存在, 最后我们还剩一个概念: 子系统. 在实际开发中, 并不存在物理的实体与子系统这个概念对应, 它只存在于架构设计的文档中

如何理解子系统

子系统是一个逻辑的概念, 物理上可能对应一个模块(Module) , 也可能是多个模块. 你可以把子系统理解为一个逻辑上的大模块(big module) , 这个大模块我们同样回去定义他的使用接口

子系统与模块的对应方式

一种情况, 也是最常见的情况, 子系统由一个根模块(总控模块)和若干子模块构成. 子系统的使用接口, 也就是根模块的使用接口.

另一种情况, 是子系统由多个相似的模块构成. 例如对于office程序来说, IO子系统由很多相似模块构成, 例如word文档读写, HTML文档读写, TXT文档读写, PDF文档读写等待, 这些模块往往由统一的使用界面.

通过上面对子系统,模块,类,函数的使用界面的解释, 你回发现其实它们是有共性的. 它们都是在定义完成业务需求的方法, 只不过需求满足方式的层次不一样. 类和函数是从语言级的函数调用来完成业务, 网络服务程序是通过网络RPC请求来完成业务, 桌面程序是通过用户交互来完成业务.

理解了这一点, 你就很容易明白 功能的使用界面应尽可能符合业务需求对它的自然预期这句话的背后含义

一个程序员的系统分解能力强不强, 其实一眼就可以看出来. 你都不需要看实现细节, 只需要看他定义的模块, 类和函数的使用接口. 如果存在大量说不清楚业务意图的函数, 或者存在大量职责不清的模块和类, 就知道他基本还处在搬砖阶段.

无论是子系统,模块,类还是函数, 都有自己的业务边界. 它的职责是否足够单一足够清晰, 使用接口是否足够简单明了, 是否自然提现业务需求(甚至无需配备二外的说明文档), 这些都提现了架构功力

功能实现准则: 高内聚耦合

系统分解的套路中, 除了自身的使用界面外, 我们还关注功能与功能之间是如何被连接起来的, 当然这就涉及了功能的实现

功能实现的基本准则是: 功能自身代码要高内聚, 功能与功能之间要低耦合.

高内聚

什么叫高内聚? 简单来说, 就是一个功能的代码应该尽可能写在一起, 而不是散落在各处. 我个人在高内聚这个方向上的养成习惯是:

  • 一个功能的代码尽可能单独一个文件, 不要和其他功能混一起
  • 一些小功能的代码可能放在同文件中, 但是中间会用 // ------------ //这样的注释行分割成逻辑上的小文件, 代表这是一段独立的小功能

代码内聚的好处是, 多大的团队协作都会很顺畅, 代码提交基本上不怎么发生冲突.

低耦合

什么叫低耦合? 简单来说就是实现某个功能锁依赖的外部环境少, 易于构建.

功能实现的外部依赖分两种. 一种是对业务无关的基础组件依赖, 一种是对底层业务模块的依赖.

基础组件可能是开源项目, 当然也可能来自公司的基础平台部. 关于基础组件的依赖, 我们的核心关注点是稳定.稳定提现在下面两个方面

  • 组件成熟度. 这个组件已经诞生多久了, 使用接口是不是已经不怎么会调整了, 功能缺陷(issue)是不是已经比较少了
  • 组件的持久性. 组件的维护者是谁, 是不是有足够良好的社区信用(credit), 这个项目是不是还很活跃, 有多少人参与其中为其贡献代码

当然从架构角度, 我们关注的重点不是基础组件的依赖, 而是对其他业务模块的依赖. 它更符合业务系统分解的本来含义

对底层业务模块的依赖少, 耦合低的表现为:

  • 对底层业务的依赖是通用的, 尽量不要出现让底层业务模块专门为我定制接口
  • 依赖的业务接口的个数少, 调用频次低

怎么做系统分解

有了系统分解的优劣评判标准, 那么我们具体怎么去做呢?

总体来说, 系统分解是一个领域性的问题, 它依赖你对用户需求的理解, 并不存在放之四海皆可用的办法.

系统分解首先要错需求归纳触发. 用户需求分析清楚很重要. 把需求功能点涉及的数据(对象), 操作接口理清楚, 并归纳整理, 把每个功能都归于某一类. 然后把类于类的关系理清楚, 做到逻辑上自洽, 那么一个基本的系统框架就形成了.

在系统的概要设计阶段, 我们一般以子系统为唯独来阐述系统各个角色之间的关系.

对于关键的子系统, 我们还会进一步分解它, 甚至详细到把该子系统的所有模块的职责和接口都确定下来. 但这个阶段我们的核心意图并不是确定系统完整的模块列表, 我们的焦点是整个系统如何被有效的串联起来. 如果某个子系统不作出进一步分解也不会在项目上有什么风险, 那么我们并不需要在这个阶段对其细化.

为了降低风险, 系统的概要设计阶段也应该有代码产出.

系统概要阶段代码的用意

  • 系统初始的框架代码. 也就是说, 系统的大体架子已经搭建起来了.
  • 原型性的代码来验证. 一些核心子系统在这个阶段提供了mock的系统

这样做的好处是, 一上来我们就关注了全局系统性风险的消除, 并且给了每个子系统或模块的负责人一个更具象且确定性的认知

代码即文档. 代码是理解一致性更强的文档

再谈MVC

虽然不同的桌面应用业务千差万别, 但是桌面本身是一个很确定性的领域, 因此会形成自己固有的系统分解套路

桌面系统程序分解的套路就是MVC架构

虽然不同历史时期的桌面程序的交互方式不太一样, 但是他们的框架结构是非常一致的, 都是基于事件分派做输入, GDI做界面呈现

系统的概要设计 - 图2

那么为什么会形成 Model-View-Controller的架构

我们第一章探讨需求分析时, 我们反复强调一点: 要分清需求的稳定点和变化点. 稳定点是系统的和兴能力, 而变化点则需要做好开放性设计.

但用户交互是一个变化点. 大家都是一个画图程序, 无论是在PC桌面和手机上, Model层是一样的, 但是用户交互方式不一样, View , Contrller 就有不小的差别

当然 Model层也有自己的变化点, 它的变化点在于 存储和网络. model层要考虑持久化, 就会和存储打交道, 就有自己的IO子系统. Model层要考虑互联网化, 就要考虑B/S架构, 考虑网络协议

View层主要承担了界面呈现的工作. 当然这也意味着它也承担了屏幕尺寸这个变化点.

Controller层主要承担的交互. 计提来说就是响应用户的输入事件, 把用户的操作转化为对Model层的业务请求.

也就是说, model层是一整体, 负责的是业务的核心逻辑. view层也是一个整体, 但在不同屏幕尺寸和平台可能有不同的实现, 单数量不会太多. 而且现在流行所谓的响应式布局, 也是鼓励尽可能在不同屏幕尺寸不同平台下共享一个view的实现. Controller层并不是一个整体, 它是以插件化的形式存在, 不同controller非常独立

这样做的好处是可以快速适应交互的变化. 比如以创建矩形这样一个功能为例, 在PC鼠标 + 键盘的交互方式下有一个RectCreator Controller, 在触摸屏的交互方式可以是一个全新的RectCreator Controller. 在不同平台下, 我们可以初始化不同的Controller实例来适应该平台的交互方式

当然也有一些MVC的变种, 比如 MVP(Model-View-Presenter) 主要是Model的数据更新发出后, 由Controller监听并Update View, 而不是View层响应 Update View

这些不同的模型差异其实只是细节的权衡, 取舍, 并不改变实质