软件架构

软件架构是什么

最适合当软件架构师的,是一线能力最强的程序员

软件架构的最高优先级是保持系统正常工作,软件架构的策略就是京可能长时间保留尽可能多的可选项

开发

一个软件系统的开发,应该就是要方便其开发团队

  • 流行的不一定好,适合的才是最好的

一个系统的架构,反映了开发该系统的团队组织结构

部署

良好的软件结构可以让系统构建完成就能部署,同时实现一键式的轻松部署是设计软件架构的一个目标

运行

设计良好的架构能明确地反映出系统运行时的需求

架构是系统运行时的一个表示

维护

维护的主要成本

  • 探秘:解决问题的最佳方式
  • 风险:解决问题衍生出的新问题

保持可选项

用例 :对系统如何响应外接请求的描述

软件系统可降解为

  • 策略:业务逻辑
  • 细节:具体实现技术,数据库、web等

在大部分时间,无法预知系统的所有用例,越晚决定实现细节,就能掌握更多信息,更有利于决策

设备无关性

高层策略与低层实现细节分离

解耦

系统可以被按层解耦,将不同层隔离开来,避免变化扩散到其他层

当对用例进行分组时,增加新用例就会对旧的用例影响降低

解耦模式

  • 源码解耦:控制源代码模块的依赖关系
  • 部署层次解耦:控制可部署模块的依赖关系
  • 服务解耦:依赖关系降低到服务层次

软件架构是生长的,从单体到相互独立可部署单元,再到服务化

设计良好的架构应该允许软件系统从单体到服务,也可以从服务退化到单体

重复

重复需要分清表面重复还是实际重复,随着软件的演进,两段重复的代码可能会变得不同

独立性

  • 开发独立性:当对系统进行解耦时,不同的模块就可以由多个团队来分工开发
  • 部署独立性:同样,解耦之后部署就可以互不影响

边界划分

软件架构设计就是一门划分边界的艺术

为了划分划分边界线,软件系统被分割成组件,这些组件的一部分是核心的业务相关组件,另一部分是非核心的但是是提供必要功能的组件,让这些非核心组件去依赖系统的核心组件

通过划清边界,可以推迟一些细节性的决策

何时何地划分

  • 画在不相关的事情中间

IO是无关紧要的,软件系统的核心,是业务逻辑

插件式架构

软件开发技术发展的历史就是如何想方设法增加插件,这些插件要么可以去掉,要么要多种实现

边界剖析

跨边界调用

边界线一侧的函数调用另外一侧的函数

  • 自律式的组件划分

边界形式

  • 部署层次的组件
  • 线程
  • 进程
  • 服务

策略与层次

本质上,软件系统是一组策略语句的集合

软件架构的重点之一,是将策略彼此分离

层次

直接管理IO的策略,层次是最低的

  • 高层策略一般变更没有低层策略频繁

当源码依赖方向统一调整到指为高层策略,可以大幅度降低系统变更带来的影响

业务逻辑

业务逻辑就是系统中真正用于赚钱或者省钱的过程,这些过程被称为关键业务逻辑,关键业务逻辑通常会处理一些数据,这些数据叫做关键业务数据,关键业务逻辑与关键业务数据通常是紧密相连的,所以将他们两个放在一起,这种对象称之为业务实体

用例

  • 输入
  • 步骤
  • 输出

请求和响应模型

对用例的输入输出对象,应该保持独立

整洁架构

许多架构都是按照不同关注点对软件进行切割

特点

  • 独立于框架
  • 独立于UI
  • 独立于数据库
  • 独立于外部机构
  • 可测试

依赖关系规则

202002031554

  • 内层圆不应该依赖外层圆
  • 外层圆的变更不应影响到内层圆

谦卑对象

谦卑对象模式是让单元测试的编写者区分容易测试的行为与难以测试的行为

一个优秀的架构,应该拥有强大的可测试性

  • 展示器与视图

不完全边界

单向边界

设计架构时,往往需要使用反向接口来维护边界两侧组件的隔离性

202002031612

边界与层次

作为架构师,需要考虑:

  • 什么地方需要设计架构边界设计
  • 设计这些边界会带来多大的成本

同时,设计边界需要深思熟虑,过度的工程设计往往比工程设计不足还要糟糕

Main组件

系统中,至少需要一个组件来负责创建、协调、监督其他组件,这个组件称为Main组件

Main组件是系统中细节信息最多的组件,即Main组件是一个底层模块,处于架构圈的外层

服务化

服务这种形式说到底只是一种跨进程或跨平台的调用方式而已,并不等于一种架构

带来的好处

  • 强解耦?
    • 未必,任何共享数据的行为都会导致强耦合。就像在数据结构的一个字段发生变更,那许多东西都要发生改变
  • 独立开发部署?
    • 大型系统一样可以采用单体模式

测试

测试组件,可以视为最外圈的最外圈程序

可测试设计

脆弱的测试问题

不良的测试设计,会导致一个对通用组件的修改产生许多测试错误

解决方法就是测试不要依赖于多变的东西

整洁的嵌入式架构

固件程序也可以指针对具体平台的编码

程序适用测试

仅仅停留在让代码能跑起来的阶段

results matching " "

No results matching " "

results matching " "

No results matching " "