什么是软件架构
软件应用架构是定义结构化解决方案的过程,它满足所有技术和操作需求,也满足通用的质量属性,如性能\安全\可管理。它包含一系列的决定,涉及广泛的方面,每个决定对质量、性能、可维护性和应用程序的成功都有重要的影响。
程序或者计算系统的软件架构是系统的结构,它由软件元素、元素的可见属性和它们之间的关系组成。架构关心公开的接口部分,元素的具体实现细节不是架构,至少不是架构主要关心的内容。
架构为什么重要
和其它许多复杂的结构一样,软件必须建立在坚实的基础上。没有考虑到关键场景,没有设计好对共性问题的处理,或者没有考虑到关键决定的长期影响,会使你的应用程序处于风险中。现代工具和平台会帮助你简化构建应用程序,但是不能代替你来设计某个具体场景和需求的应用程序。烂的架构会使应用不稳定、不能满足现在和将来的商业需求,也很难部署到生产环境中。
系统应该考虑到用户、IT基础设施、商业目标。对于这些方面,你应该列出关键场景、标识重要的质量属性以及关键的满意点和不满意点。如果可能的话,对这些方面设计度量指标。
用户,业务和系统目标
必须在用户,业务和系统上做权衡。总的用户体验通常也是业务和系统(IT基础设施)的功能,改变其中任何一个也会影响用户体验。改变用户体验需求,也会影响业务和系统需求。
架构关注程序内部的主要元素和组件。数据结构、算法、元素的实现细节是设计需要考虑的。架构和设计也经常会有重叠。
当考虑软件架构时考虑如下抽象问题:
l 用户如何使用应用程序?
l 应用如何被部署到生产环境并被管理?
l 应用的重要属性需求是什么,如安全、性能、并发、国际化、配置?
l 应用程序是如何被设计得更加灵活和可维护?
l 现在或者部署之后影响到应用程序的架构趋势?
架构的目标
架构通过use cases寻求构建商业需求和技术需求之间的桥梁,然后找到方法来实现这些use cases。架构的目标是标识影响程序架构的需求。架构必须考虑设计决定的总体影响,必须权衡用户、商业、系统。
Keep in mind that the architecture should:
l 展示系统的结构,隐藏实现细节
l 领悟所有的用例和场景
l 努力实现不同利益相关者的需求
l 处理功能和质量需求
架构蓝图
理解那些影响架构决定的关键力量非常重要,这些力量将影响架构如何做出决定。
考虑如下关键趋势:
l User empowerment支持user empowerment的设计是灵活的、可配置的,关注于用户体验的。设计程序时,考虑一定程度的用户个性化和选项。允许用户定义如何与你的程序交互,但是也不要过度使用一些不必要的选项和设置。理解关键场景,越简单越好。使得很容易找到信息并且使用你的程序。
l Market maturity充分利用市场成熟产品,如已经存在的平台和技术。使用模式来解决共性问题。
l Flexible design灵活设计利用松散耦合来提高重用性和可维护性。插件设计及soa、restful等。
l Future trends构建架构时,考虑到将来可能影响你设计的趋势。例如,考虑未来富UI和多媒体,增加网络带宽等。
架构设计准则
一般来说,设计是会延续的,因为你无法一次性了解到所有东西及未来的趋势。当你了解得越多,以及外面需求的变化,你的架构会不断的演化。在头脑中树立这种意识,架构不是一次完成的。
当你创建架构设计时,考虑如下问题:
l 架构的最基本部分是什么,当系统出现问题时,它们是最大的风险
l 最容易改变的部分是什么,哪些设计你可以延迟
l 最关键的假设是什么,如何测试它们
l 什么情况下需要重构你的设计
不要设计过头了,也不要做你不能确认的假设,保持开放的态度,接受改变。
关键架构准则
l Build to change instead of building to last.考虑到程序是要随着需求而改变的,设计灵活性以支持这些变化
l Model to analyze and reduce risk使用设计工具,uml或者其它工具来帮助你捕获需求并作出架构决定,并且分析它们的影响。但是,不要把model扩展为正式的程序,它会压制你迭代和调整设计的能力。
l Use models and visualizations as a communication and collaborationtool高效的设计交互,对你做决定,即将对设计做出的变化,对好的架构来说非常重要。使用模型、视图等与所有利益相关方进行沟通,分享你的设计,能够对架构带来很大改善。
l Identity key engineering decisions标识错误最可能发生的区域。如果在第一次就把这些标识清楚,设计将会更加灵活,也会很少因为变化而崩溃。
考虑使用增量和迭代来改善你的架构。测试你的架构时考虑如下方面:
l 当前架构你做出了哪些假设
l 架构满足的显式及隐性的需求
l 关键风险点
l 如何减轻关键风险
l 在基线或者最新架构方案的基础上,架构如何演进