系统设计的三板斧——抽象、具象和演算

背景

对于技术来说,每一个系统都少不了最重要的一个环节,系统设计。

系统设计的成功与否直接决定了后续的系统开发能否成功。

这次的分享,我们将系统设计的方法简化为三板斧,简单易懂,居家旅行学习进修必备。

三包承诺:包记住,包理解,包会用。如有问题,请再看一遍。如想快速浏览,可以先看总结。

大纲

1 系统设计的基本流程

2 三板斧的招式

3 实例讲解,权限系统设计

4 总结

什么是系统设计

The process of defining the             定义(产出)

architecture,                  架构

components,                  组件

modules,                    模块

interfaces,                   接口

and data                    数据

for a system to satisfy specified requirements.   需求(目标)

1 系统设计的基本流程

1.1 软件开发流程

  • 1 需求分析
  • 2 概要设计
  • 3 详细设计
  • 4 系统开发
  • 5 系统测试
  • 6 软件交付

软件开发流程,详细内容可以参考: https://baike.baidu.com/item/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E6%B5%81%E7%A8%8B

需求分析就是一个很专业的工作,对于大型的软件开发,也有专门的需求分析师,所以这里面的方法和流程也还有很多细分的内容,有兴趣的同学可以继续挖掘。

系统设计主要就是2、3两部分,大学毕业设计的时候,应该也都有深刻的印象,自己的文档是怎么写出来,怎么组织和编排的吧。

1.2 系统设计的流程

系统设计的内容可以用16或者32课时来专门开一课,大学时候应该也有这样的课,可能是选修吧。

详细内容可以参考: 从 0 到 1 教你设计业务系统 https://36kr.com/p/1722044334081

1.3 总结,系统设计的基本流程

上面的软件开发流程和系统设计流程,看着就很复杂,分工很细,要完全遵守这些方法来做互联网产品开发的话,很多人是无法想象的,2周上线,1天1个版本?

所以,上面的流程都是来自传统的企业软件开发方法。而传统软件的开发周期,最少也是半年、一年的周期,交付物也都会比较严格,也不会有持续迭代一说。

传统企业软件开发,有很多是外包公司,规模很大,类似富士康的工厂。而规模的基础就需要标准化,遵守各种认证体系的要求,这样也更能被企业认可和信任。

但是,这些流程、方法,对于我们互联网研发就很不合适,系统设计也是。所以,才有了本文的核心方法。

2 三板斧的招式

2.1 第一招:抽象,万物归一

1 人,主体对象

实体模型,数据结构

2 事,核心功能

组件模块,功能需求

3 物,资源要求

系统规模,开发周期,架构设计

宏观上的面,提炼和定义,不拘泥细节。

从繁杂的系统中剥离、提炼,抽象出来我们系统的核心,定义好系统的人、事、物,也就有了系统的大致样貌。

抽象,这是最重要的一步,也是最厉害的一招。

2.2 第二招:具象,有血有肉

1 数据结构设计

对象的属性,数据表

2 业务功能设计

功能模块,任务清单

3 系统架构设计

性能、并发、伸缩、扩展、安全

微观实现的点,为后续的编码扫平模糊。

系统设计在这一招完成后,基本上就要全面完工了,交付给开发来编码。如果这时候还有不清晰的地方,还有遗留的点,那么后续就会出现很严重的需求变更、技术变更、甚至重构,会严重影响项目开发的周期和质量。

具象,这是需要细致且耐心的一步,也是势大力沉的一招。

2.3 第三招:演算,活灵活现

1 业务流程

让功能细节发生互动(业务恋爱)

2 数据流程

让对象之间发生关系(数据怀孕)

3 模拟操作与系统预估

模拟的运转和系统压力评估(成长烦恼)

流程不通,操作不顺,系统瓶颈,及早发现和补充完善。

纯脑力运算的过程,可能是设计者来做,也可能是要系统相关人一起来做。

这里用时2小时或者一起开个会,把系统设计的方方面面都模拟的运转起来,各个环节,各个角色带入进来,发现问题马上调整前面的抽象和具象的设计。

演算是一个快速查缺补漏的环节,也是对系统设计进行方案优化、调整的最后环节,这里投入的每一分钟都是十倍百倍于后续研发阶段的调整时间效率。

演算,这是最容易忽略的一步,也是最难的一招。

2.4 总结,系统设计的三板斧

围绕系统设计中的人、事、物,我们通过宏观层面的抽象,提炼和定义出来核心内容,在通过微观层面的具象,把各个细节补充完善,最后,运用演算,让这个系统在我们的脑子里面活起来,重复这三板斧,完善我们的系统设计。

3 实例讲解,权限系统设计

介绍:权限系统管理着应用和服务之间的调用关系。应用要调用服务的接口,必须先申请对应的服务接口权限才可以。

3.1.1 抽象:权限系统的核心对象(主体)

1 主要对象

应用,服务

2 派生对象

接口,应用请求服务

权限,接口权限

3 外部对象

网关,系统平台,第三方服务等

提炼权限系统内部的主体对象,确定系统的数据模型。

3.1.2 抽象:权限系统的核心功能(硬性)

1 权限相关功能

应用端申请,服务端审批,查询

2 后台管理功能

服务信息和扩展权限的配置

3 扩展功能

消息通知,权限推送

定义必须的应用的全后端功能,扩展的与外部系统的交互功能。

3.1.3 抽象:权限系统的资源要求(软性)

1 权限的管理系统,不涉及权限验证

系统并发量很有限,性能要求低

2 平台内应用、服务的权限依赖度高

系统的安全和稳定性高

3 内部和外部服务的权限定义差别大

扩展性要求高

系统的架构设计不必过于复杂,保证应用程序的安全和稳定性,定义好系统的可扩展性。

3.2.1 具象:权限系统的数据结构

应用相关

服务相关

接口相关

申请相关

审批相关

标准字段

2 服务配置表 tb_paas

服务信息

推送相关

外部相关

扩展相关

标准字段

3 操作日志表 tb_log

数据模型

新旧数据

标准字段

3.2.2 具象:权限系统的业务功能

细化每一个功能的处理过程,要结合交互页面,操作流程,数据输入和产出等。

3.2.3 具象:权限系统的系统架构

1 分层模型,前后端分离

前端展现和交互,后端数据和逻辑,前后端耦合度低

2 服务的权限订阅和推送,预留第三方服务和扩展权限

定制化多端推送,扩展能力强

3 多机分布式,定时任务更新权限和通知

资源伸缩性强

**架构演化:**单机 -> 分布式,单库 -> 主从库 -> 缓存层 -> 数据分拆(水平、垂直) -> 应用分拆(微服务)

架构选择,只有合适与否,没有好坏之分。

3.3 演算:数据流程、业务流程和交互模拟

1 权限申请流程

方便查找服务,方便申请接口权限

2 权限审批流程

方便查找服务,方便申请接口权限

3 接口权限申请的状态变更

申请、审批和推送、通知,把开发者、服务方、网关、服务都串联起来

流程,让整个系统运转起来,是一个活的系统,不再是冷冰冰的数据结构和系统框架。

考虑开发者和服务方的用户,带入用户的立场和操作,更好地模拟整个系统的交互体验。

3.4 总结,实例讲解,权限系统设计

这里的实例比较简单,但毕竟是最近设计开发的一个系统。

而对于更加复杂的系统,方法还是互通的。

定义好,写下来,画下来,这就是一个系统设计和项目文档。

当然系统设计不仅仅是上面呈现出来的内容,还有关于接口,任务清单等内容。

4 总结,系统设计的三板斧

一句话形容,从宏观到微观,互动更长久。

抽象,先从宏观层面做好抽象;

具象,再从微观层面补充完善细节;

演算,全流程的模拟,查缺补漏;

重复上述三板斧,不断完善系统设计。

注意:不用纠结未知和差异化太大的部分。

系统设计的三板斧,相信不仅仅可以用在系统设计中,在其他的很多方面应该也是类似,比如:写作。

主题 -> 目标

创意 -> 抽象(人、事、物)

细节 -> 具象(有血有肉)

故事 -> 演算(活灵活现)

在最后,强调一遍,抽象和推理是数学的重要能力,数学绝对是极其重要的学科,掌握好数学,能够更好地掌握科学方法,而不仅仅只有个人的经验和直觉。

版权声明:
作者:一凡sir
链接:https://jkboy.com/archives/12924.html
来源:随风的博客
文章版权归作者所有,未经允许请勿转载。

THE END
分享
二维码
打赏
海报
系统设计的三板斧——抽象、具象和演算
三包承诺:包记住,包理解,包会用。如有问题,请再看一遍。如想快速浏览,可以先看总结。
<<上一篇
下一篇>>