架构师之路(一) 什么是软件架构

一、 山重水复疑无路

架构师在架构实践过程中,经常面对的困惑:

六个实际问题的困惑

大系统架构设计,如何开始?

总觉得需求不清晰,影响架构设计!

非功能需求重要,但如何设计?

将系统划分模块,如何更合理?

架构设计如何,哪些没考虑到,心里没底

想用新技术,纠结

两个职业发展的困惑

缺乏指导,不知所措,老司机,谁能带带我

缺乏总结,仍对下一个项目心虚

写这系列的文章,来逐步解决上面的困惑。

二、软件架构是什么?

   对于软件架构的定义,仁者见仁,智者见智。目前,业界比较流行的两大流派是组成派和决策派,这两派的概念相辅相成,具体如下:

   组成派:软件架构 = 组件 + 交互。

   决策派:软件架构 = 重要决策集。

上述两大流派的描述过于抽象,不利于理解,本人更喜欢下述关于软件架构的描述,通俗易懂。

     1.软件架构是一个系统的草图。

     2.软件架构描述的对象是直接构成系统的抽象组件。

     3.各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

     4.在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。

     5.在面向对象领域中,组件之间的连接通常用接口来实现。

   从本质上讲,架构设计毫无疑问是需求驱动而非模型驱动的。还有的专家提倡的“用例驱动的架构设计”观点,其实存在着严重缺陷:

  1. 需求=功能+质量+约束
  2. 用例是功能需求的实际标准
  3. 用例不涉及非功能需求

三、软件架构的重要性

  • 软件架构能够满足系统的品质
  • 架构设计使受益人达成一致的目标
  • 架构设计能够支持计划编制过程
  • 架构设计对系统开发的指导性
  • 架构设计能够有效地管理复杂性
  • 架构设计为复用奠定了基础
  • 架构设计能够降低维护费用
  • 架构设计能够支持冲突分析

四、软件架构的目标

功能:功能上必须满足需求

高内聚低耦合:架构是恰如其分的

可靠性:软件系统必须非常可靠

可用性:系统必须可用

可维护性:一个易于维护的系统可以有效地降低技术支持的花费

安全性:系统的安全性非常重要

可扩展性:必须能够在用户的数目增加很快的情况下,保持合理的性能

 五、架构设计的驱动力

   何为驱动?通过本质规律去建模世界,才能以“一”推演万物。种种推演的过程,皆是要去寻找某种驱动力量作为分析或建构的起点。

   何为“力”?所谓“力”,其实是一种隐喻。不同的影响因素会决定着架构师的设计决策,而这些决策之间又相互影响着,或者相吸,或者相斥,绝对不能孤立看待。

   如何寻找架构驱动力呢?正如在《架构之美》中John Klein、David Weiss写道:

软件架构师的首要关注点不是系统的功能。……你关注的是需要满足的品质。品质关注点指明了功能必须以何种方式交付,才能被系统的利益相关人所接受,系统的结果包含这些人的既定利益。

于是,架构分析与设计就变成了对软件系统的影响力识别,这种设计的驱动力即我们所谓的RAID分析法。

六、RAID分析法

所谓RAID分析法,即识别软件系统的风险(Risk)、假设(Assumption)、问题(Issue)、依赖(Dependency),准确地说,就是

  1. 评估风险

   风险其实就是未来可能出现的问题。我们在软件设计的过程中,既要满足现实,却又需要预测未来,如何做到架构设计的恰如其分。

     2. 明确假设

   我们往往会忽略为系统给定假设(Assumption),而事实上,这种假设往往代表了关键的架构约束。架构约束是一种非常重要的驱动力。Roy Fielding如此勾勒出约束的重要性:

属性是由架构中的一组约束所导致的。约束往往是由在架构元素的某个方面应用软件工程原则来驱动的。例如,统一管道和过滤器(uniform pipe-and-filter)风格通过在其组件接口之上应用通用性原则——强迫组件实现单一的接口类型,从应用中获得了组件的可重用性和可配置性的品质。因此,架构约束是由通用性原则所驱动的“统一组件接口”,目的是获得两个想要得到的品质,当在架构中实现了这种风格时,这两个品质将成为可重用和可配置组件的架构属性。

   我们在明确假设时,需要将这些约束甄别出来,以之作为架构设计的驱动力。

  3.分析问题

   分析现在存在的问题,评估未来风险。

  4.识别依赖

   如何分解(内聚),如何协作(耦合),这就是我们需要遵循的高内聚低耦合设计原则。

七、软件架构设计的误区

  1. 设计架构就是搭框架

https://i-blog.csdnimg.cn/blog_migrate/1b98f8a36dd8bd11d6c94b97e513fc67.png

  1. 软件架构师不必懂需求
  2. 架构=理想设计
  3. 架构=模块+接口
  4. 只注重功能设计,忽略了约束
  5. 只注重功能设计,没考虑非功能性设计
  6. 忽略了风险
  7. 不计成本的架构设计

   路漫漫其修远兮,吾将上下而求索。在软件架构之路越走越远。

原创诗词一首
卜算子•别妻儿
泪沾蛾眉舒,
一走一回顾。
同甘共苦十余年,
风雨兼程路。
行计总匆匆,
儿女哪得顾。
遥看云深归何处,
斜阳秋色暮。

 

 

  • 3
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值