序言
类比的思维模式?
软件技术专业同学如何与非技术同学沟通?先推荐一个思维方式:类比思维,通俗说法就是“打比方”。这是一个对技术同学有特别用处的思维方式。在研发链条中,技术同学分别需要与产品/设计/测试/运营等多个不同专业的人员沟通,那么如何讲明白某个功能的技术优缺点,就特别考验一个技术人的综合能力。
本次尝试使用类比思维总结架构设计背后的逻辑。
前文
什么是软件架构设计?
拿上面这个问题去问其他人,相信会得到很多不一样的答案。不仅仅在实际工作中,在网络上搜索“软件架构设计”也有非常多的回答,并且这些答案不尽相同。对比“设计模式”,设计模式在大家的回答中大部分都是“GOF设计模式”,即使有所变化也不会脱离GOF设计模式的一些思想,这说明了架构设计本身不是一个简单问题。
在架构设计过程中,“设计”本身严格来说并不包含功能代码,最多也只到伪代码层级,那么架构设计究竟做了什么?写代码的同学有时吐槽架构师是PPT架构师,PPT架构师这个叫法在某一个维度上也是对的。
大厨和架构师对比有什么同异点吗?
大厨的能力是什么?一份美食需要依照菜谱制作而成,但是绝大多数情况下菜谱都不是大厨原创的,类似于大多数架构设计的组件或构件都是从行业中拿来的一样,架构设计的原创性非常少。能在行业基础层有所创新的人都可以称之为幸运儿,所以我们在此讨论的设计更多的是基于业务应用的软件架构设计。
对于一份美食来说,食材都是已有的菜谱都是现成的那么大厨的能力是什么?也许有同学会说是厨艺,什么是软件架构的厨艺?
正文
架构师 VS 大厨师 的类比
大厨的能力
问题:如何把大象放进冰箱里?
回答:第一步打开冰箱门,第二步把大象放进去。
如何做好一份美食?第一步要有自己的菜谱,第二步使用工具制作出来。以蛋炒饭为例。
菜谱
材料 | 蛋炒饭 |
---|---|
主料 | 过夜的米饭、鸡蛋 |
辅料 | 胡萝卜、香葱、火腿 |
调料 | 盐、胡椒粉、香油 |
制作
大厨的能力就是使用 “菜谱” 制作出 “美食”,那么问题来了,是“菜谱”重要还是“制作”重要?在互联网信息时代,网络上有数不胜数的菜谱,大厨的能力不是知道多少菜谱,而是要在菜谱之上,结合用户的种族地域习惯等进行制作,才能称之为美食。
设计的艺术
架构设计是一个多维度的问题(复杂性问题),多维度问题的本质是包含多个要素并且要素间非线性关联关系相互影响,所以有很多种什么是架构设计的回答,不能算错只能说不够全面。
架构设计=架构+设计
架构通俗说是架子、结构,类比建筑行业是各种构件(屋架、梁、板、柱等)组成的能够承受各种作用的体系;对于软件行业来说各种构件就是开发语言Language、组件Component、框架Framework、中间件Middleware、服务器Server、网络Network等。
设计通俗说是设想、计划,一般情况下指“把一种设想通过合理的规划、周密的计划、使用各种方式表达出来的过程”;对于软件行业指的是使用上面技术构件,支撑业务需求的表达过程,软件的表达结果是代码(Code),设计的表达结果是视图(View),并且PPT是一个非美术专业人士也能够专业制图的工具,所以说“PPT架构师”是有一定道理的。
结合上面两点,架构设计可以总结为
使用各种技术构件(语言Language、组件Component、框架Framework、中间件Middleware等),组成能够支撑业务的作用体系,通过合理的规划使用视图(View)方式表达出来的过程。
对于架构大厨来说,它所拥有的材料就是“行业技术”和“用户业务”,设计就是基于这两点进行视图(View)的逻辑推理。
架构设计菜谱
材料 | 软件架构设计 |
---|---|
主料 | 用户业务、行业技术 |
辅料 | 功能性设计 |
调料 | 非功能性设计 |
这个菜谱有什么问题?太简单了。功能性设计怎么设计?非功能性设计要设计什么?这些设计过程并没有行业标准定义,这也是为什么很难有人讲清楚架构设计的问题。架构设计的难点就是结合行业技术,如何定义一套适合自己、适合团队并且适合公司阶段的设计过程。
模型映射方法
模型映射设计方法是一种架构设计的设计过程。作为专业人士和非专业人士的一个重要区别就是专业名词,让我们用专业名词定义设计材料。
用户业务 → 用户故事,行业技术 → 技术方案
模型映射设计方法就是抽象业务需求到用户故事,然后从用户故事出发,经过技术故事加持,通过领域模型、开发视图、部署架构和重点过程四个视图View的逻辑设计,最终映射到技术方案上的过程。
设计过程各环节总结如下
环节 | 表达形式 | 作用 |
---|---|---|
业务需求 | 文档/视频/图片 | 定义业务需求范围 |
用户故事 | UserStory | 定义业务设计范围 |
技术方案 | 云计算架构 | 定义技术构件范围 |
技术故事 | UserStory | 扩展技术约束条件 |
领域模型 | 模型视图View | 业务映射模型数据 |
开发视图 | 分层架构视图View | 业务映射技术模块 |
部署架构 | 物理部署架构视图View | 业务映射网络部署 |
重点过程 | 过程视图View | 复杂过程分析定义 |
形象化架构设计画板如下,从左侧的业务需求出发,经过中间两个UserStory抽象加持和四个视图View的逻辑设计,最终映射到专业技术方案的过程就是模型映射设计方法。
在整个设计的过程中,贯穿始终的是非功能性约束。
产出物视图
问题:架构设计的产出物是什么?
回答:视图View,设计表达一般使用“视图View”,视图是通过点、线、面抽象描述一个系统切面的图形,重点关注边界。
下面是一个典型的分层架构视图,分层架构视图是“开发视图”的一种表现形式,主要作用是根据业务需求切分业务,定义技术模块子系统及关联关系等,便于研发团队分工合作。
除了分层架构图,还有一种典型的设计视图。
下面是另外一种使用非常多的设备网络架构图,设备网络架构图是“部署架构”的一种表现形式,主要是描述软件系统在硬件网络层面的结构。
非功能性约束
问题:功能性 VS 非功能性有什么区别?
回答:功能性就是软件系统满足用户业务需求必须具有的特性,非功能性就是指除功能性以外必须具有的特性,
非功能性特性并没有一个行业标准定义,一方面是因为非功能性约束与业务需求有关,另一方面也跟具体的技术方案选择上相关。比如一个纯内网使用的单机系统对比公网支持远程使用的软硬件系统,明显后者的非功能性约束会高很多,这里总结一般情况下需要关注的点。
五性约束
复杂性设计
问题:架构设计为什么是一个复杂性问题?
回答:设计过程除了上面的业务与技术外,还需要考虑团队能力、交付周期等因素。
架构设计是一个复杂问题,所以在一些文章中也将“架构设计”称之为“复杂性设计”,下面是两类典型的不确定性。
业务与技术的不确定性
团队与周期的不确定性
总结
架构大厨的菜谱。
材料 | 模型映射设计 |
---|---|
主料 | 用户故事、技术方案 |
辅料 | 技术故事、领域模型、开发视图、部署架构、重点过程 |
调料 | 可用性、可靠性、安全性、维护性、扩展性 |
推荐
软件设计六字真言:高内聚低耦合。
进阶传送门
结构化架构设计进阶。