CIO了解:应用架构的评价标准与分层策略
3250
2016-05-31 18:51
文章摘要:评价应用架构设计是否成功,主要看期能否通过定义结构元素与它们之间协调的机制 ,来直接满足关键质量需求,并为产品开发人员提供指南。成功的应用架构具体应该有如下的品质: 良好的模块化 每个模块职责明确,模块之间松耦合,模块内部高内聚,并且合理地实现了信息隐蔽。  适应功能需求变化,适应技术变化 典型情况




    评价应用架构设计是否成功,主要看期能否通过定义结构元素与它们之间协调的机制 ,来直接满足关键质量需求,并为产品开发人员提供指南。成功的应用架构具体应该有如下的品质:

良好的模块化


   每个模块职责明确,模块之间松耦合,模块内部高内聚,并且合理地实现了信息隐蔽。


 适应功能需求变化,适应技术变化


     典型情况是,应该保持具体应用的相关模块和领域通用模块的分离,技术平台本上关模块与具体技术的应用模块和分离,从而达到隔离变化的效果。


对系统动态运行良好的规划


    应该标识出哪些是主动模块,哪些是被动模块,明确模块之间的调用和加锁机制,并说胆关键的进程、线程、队列、消息等机制 。


明确、灵活的部署规划


   这里往往牵涉到可移植性、可伸缩性、持续可用性以及互操作性等大型企业级特别关注的质量属性架构策略。


    应用架构设计以业务架构为主了的设计依据,以数据架构为基础,首先勾勒出概念性的架构,再结合具体的技术平台制定实际架构方案。在考虑架构设计的时候,必须注意如下关键要素:


是否遗漏了至关重要的非功能性需求


 非功能性需求是最重要的架构决定因素之一。所谓非功能性需求,主要包含两个部分:质量属性和约束条件。非功能性需求很多情况下存在一定的相互矛盾,所以只有少数几个质量属性在架构设计中是最重要的,它通常左右着架构风格的选择。但是,软件系统非功能性需求的满足,仅凭编程级的努力是达不到的。比如为了提供高可靠性,往往涉及错误检测、、修复等,这就是需要架构设计中非常重视非功能性需求。功能是重要的,但如果仅仅盯着功能而忽视了非功能需求,则可能导致架构设计的失败。


是否适应数量巨大且频繁变化的需求


  需求的变更即蕴藏着风险又包含了机遇。一方面,任何变更都意味着时间和金钱的消耗,并且在大量变更以后程序可能被搞得混乱不堪,势必引起BUG增多、产品质量下降;另一方面,需求变更也蕴含着机遇,对应用架构而言,这个机遇就意味着极力设计出更稳定的架构,最终这个架构能够支持需求在一定范围内“随需而变”。


能否从容设计架构的不同方面


 应用架构必须对开发提供足够的指导和限制,这无疑意味着应用架构的工作是复杂的。应用架构必须深入研究软件系统运行期间的情况,合理划分不同部分的职责,权衡轻重缓急,并制定相应的并行、分时,缓存和批处理等设计决策。应用架构设计必须掌握系统化的方法,对复杂问题“分而治之”,分解成独立的范围。然后再综合考虑各个视图之间的相互支持、互相影响等问题。


能否及早验证架构方案并做出调整


 当现有应用架构和未来架构差距较大、改造的周期较长时产, 应采用“总体规划、分步实施、边建边用”的原则,优先开发基础性功能应用架构,待试运行稳定,就可以正式投入使用。在实际应用过程中,如果出现了更适用的新技术和新的功能系统,可以逐步地加以补充和完善。这样既可以保证系统能够快速建设、稳定运营起来,又可以保证整体的先进性。



版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)信息科技有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)信息科技有限公司将追究其相关法律责任。

评论