“ 7种武器”
对于这“ 7种武器”修炼是
个漫长过程除了需要不断学习理论、原理的外还要不断在软件Software架构设计工作中去实战而且这样实战机会有限
毕竟公司项目就那么多失去次这样机会就只有等下个项目了所以我想在这里就具体怎样进行软件Software架构设计提供些思路和思路方法给大家希望能对大家在软件Software架构设计工作中有所帮助
软件Software架构设计
目对于外包业务类型
项目软件Software架构设计目和产品类型项目有所区别在这里主要讨论外包类型项目软件Software架构设计目1、为大规模开发提供基础和规范标准
并提供可重用资产软件Software系统大规模开发必须要有定基础和遵循定规范标准这既是软件Software工程本身要求也是客户要求架构设计过程中可以将些公共部分抽象提取出来形成公共类和工具类以达到重用目2、
定程度上缩短项目周期利用软件Software架构提供框架或重用组件缩短项目开发周期3、降低开发和维护
成本大量重用和抽象可以提取出些开发人员不用关心公共部分这样便可以使开发人员仅仅关注于业务逻辑实现从而减少了很多工作量提高了开发效率4、提高产品
质量好软件Software架构设计是产品质量保证特别是对于客户常常提出非功能性需求满足软件Software架构设计
原则软件Software架构设计必须遵循以下原则:
1、满足功能性需求和非功能需求
这是个软件Software系统最基本要求也是架构设计时应该遵循最基本原则2、实用性原则
就像每个软件Software系统交付给用户使用时必须实用能解决用户问题样架构设计也必须实用否则就会“高来高去”或“过度设计”3、满足复用
要求最大程度提高开发人员工作效率软件Software架构设计
几种视图我们常常在讨论架构设计该做些什么
时候或是在架构设计评审会议上会提出各种各样问题例如开发人员该如何记录Log事务如何控制？怎样才能提高我们开发人员工作效率即在单位时间内更有品质完成更多功能？怎样满足客户非功能性需求？怎样让生产环境平台管理人员更好维护系统？上面这些问题
实际上是软件Software系统区别干系人站在区别角度上提出问题要回答上面这些问题我们就得从区别视角来看待软件Software架构设计这项工作1、逻辑架构视角
从系统用户角度考虑问题设计出来软件Software架构能够满足业务逻辑需求能够处理现在越来越复杂业务逻辑需求2、开发架构视角
从系统开发人员角度来考虑问题设计架构要易于理解易于开发易于单元测试最好做到让开发人员可以用最少代码行数完成功能开发3、运行架构视角
从系统运行时质量需求考虑问题特别关注于系统非功能需求客户常常都会要求我们系统功能画面最长响应时间不超过4秒能满足2000个用户同时在线使用基于角色系统资源安全控制等4、物理架构视角
关注系统安装和部署在什么样环境上例如现在最流行企业应用服务解决方案IBM Http Server ＋ WebSphere Application Server ＋ DB2WebLogic + Oracle等5、数据架构视角
如今我们开发各类系统如MISERPSAP基本上都是对各类数据操作把堆不太好懂数据展现成用户容易看懂数据自动处理各类数据运算等所以数据持久化是十分重要件事情软件Software架构设计
几个步骤1、分析需求和理解业务模型(或领域建模)
并选定关键Use 
软件Software
需求可以分为从用户视角和开发人员视角来看从用户角度看又可以分为功能性和非功能性需求我们必须从区别视角和级别去全面认识需求并分析需求理解业务模型实战表明常常被我们忽视非功能性需求常常会导致整个项目失败理解业务需求最好
方式莫过于进行领域建模领域建模和需求分析往往是交替穿叉进行领域建模主要有以下 3个方面作用:◆探索复杂问题
弄清领域知识Martin Fowler曾经说过他采用面向对象思路方法最大好处就是它有助于解决更为复杂问题领域建模本身作为辅助思维工具帮助我们将注意力始终保持在最为重要业务概念及其关系上使我们能够不断深入地系统对需求进行分析和认识领域建模往往是个从模糊到清晰从零散到系统过程◆决定功能范围
影响可扩展性任何模型都是对现实世界某种
抽象这种抽象就会忽略某些东西例如忽略对象属性和对象间关系而这些忽略往往都是带有定目性这种忽略就决定了功能范围模型揭示了各种功能背后结构如果说定义功能相当于“拍照片”话那么领域建模就相当于“做透视”更加关注问题领域内在结构相当于对问题领域进行了定抽象良好领域模型不仅能很好支持现有功能而且还可以在定程度上支持未来可能出现新需求体现良好可扩展性◆提供交流基础
促进有效沟通领域建模通常会使用UML图作为呈现方式这样为我们沟通提供了方便当然有时候文字在描述某些特定领域问题时可能更适合可以灵活运用在我们公司
实际软件Software开发流程中往往领域建模缺少这环节这可能是在以后工作中需要进步提高的处虽然我们总是期望架构设计师能全面掌握需求
但由于时间和精力限制摆在我们面前现实就是架构设计师没有时间对所有需求进行深入分析所以我们策略就是“把好钢用在刀刃上”即把大部分时间和精力花在对决定架构最重要关键需求上在选择关键需求时要注意:高优先级需求往往是从用户角度来看可能并不是真正关键需求在
RUP实战者指南
书中向我们讲述了如何确定关键功能需求？A.作为应用核心或实现了系统主要接口功能B.必须被实现功能即如果这些功能不被实现则开发出来软件Software就失去了价值C.覆盖了系统架构些方面但没有被其他重要Use 覆盖到功能2、分别从各个视角来考虑软件Software架构
方方面面软件Software
架构设计必须考虑到各方面根据前期工作确立领域模型关键需求系统约束等进行设计必须从系统用户开发人员系统管理员部署管理员数据管理员等人员角度去分析并解决问题比如说如果我们运行架构采用Cluster方式时就必须小心Cache和Session等使用；如果我们业务逻辑要求我们要操作多个数据库时就要考虑采用支持 2阶段事务提交方式只有将这些方方面面
问题都考虑到了这样架构设计才是完整至于每个视图中我们应该设计到什么细节这问题实际上和整个项目过程定义有关例如如果我们有专门安排数据库概要设计活动那我们在架构设计过程中就可以只需要关注更高层次数据库特性及数据库的间关系而每张表数据字典可以在后续相关活动中进行设计但如果没有这样活动那我们就要细化到每张表每个栏位以及表的间关系3、解决技术面
重点问题和难题在软件Software架构设计
过程中我们往往会需要攻克些技术面重点问题和难题这完全是项极其需要扎实理论知识和丰富实战经验支撑工作例如我们如何提高整个系统性能？如何能很好导出极其复杂“中国式报表”(般比西方国家产出报表要复杂很多而且很多开源BI类框架并不能完全解决问题)？当遇到确实是很困难
问题可以去百度下或Google下也可以去请教公司资深技术人员或专家或者召开小范围技术专题讨论会议采用脑力激荡思路方法试着找找答案这样才能提高工作效率4、召开架构设计评审会议进行同行评审
架构设计评审是极其重要
环我曾将其形容为“ 7种武器”中离别钩就是在会议上同行们可能会提很多问题或意见而且很多意见很尖锐所以定要虚心接受并做好记录正所谓“良药苦口利于病忠言逆耳利于行”在评审会议的前
我们要完成很多准备工作最好是能准备份简明扼要电子简报把最重要问题列出来这样在进行评审会议时就不会漫无目在会议前就将这些资料发给和会人员请他们抽空先了解下在会议进行时要学会控制会议进度提高会议效率5、针对关键Use
在设计架构上实现功能来验证架构对于架构设计
验证也是项十分重要工作其验证技术有很多种在我们公司通常会采用Sample形式即XP中所说迭代0RUP中所说切片这样做好处是既可以从实际产品角度出发来有效验证架构是否满足要求又可以比抛弃型原型验证技术节省成本这个Sample绝不是我们在解决架构设计中
问题时拿来做实验些代码拼凑而是完整实现某关键Use 符合架构设计和系列规范标准可交付代码及相关文档同时这个Sample可以作为你在给大家讲解或培训架构时教材也可以作为开发人员使用此架构进行开发蓝本甚至是只需要复制粘贴加上简单修改即可6、 交付给客户Review
这
环节在很多公司可能并不存在他们软件Software架构并不定需要客户Review但像我们这种做服务公司最重要就是客尊落实到软件Software架构设计这活动就是让客户理解并接受你架构设计方案同时客户也会起到帮你验证架构作用通常我们架构得到客户认可后便可进入大规模开发在交付给客户Review时
通常可能会以会议形式进行Review所以我们可以参照评审会议时好做法来召开会议在这里就不再冗述软件Software架构设计
常见误区及解决办法1、架构设计
常常会“高来高去”所谓高来高去实际上就是我们架构设计仅停留在模型阶段但也绝不是产生第支样例程式2、架构设计时常常会在某些方面过度设计(Over engineering)
为了些根本不会发生变化而进行系列复杂设计这样设计就叫过度设计往往会带来资源浪费并且会增加开发工作量或难度虽然我们必须考虑到系统扩展性可维护性等但切忌过度设计有时候或许你并不能判断出哪些设计是过度设计此时你可以请教你PM让他站在整个项目高度来帮你决策下3、架构(Architecture)不是框架(Framework)
也不是简单将几种框架或技术组合框架本身也是有架构框架般是针对于某方面或领域重用性和可扩展性非常好半成品我们可以用句较为经典话来整理总结:框架是软件Software架构不是软件Software框架是种特殊软件Software我们在工作中通过将许多方面可重用工具类公共类基础类等抽象出来即可形成些可重用框架4、架构设计绝不是新技术展示平台
合适技术才是对于项目有利技术必须考虑到开发人员能力和维护人员能力作为名架构设计师应该更多考虑如何平衡业务需求织织运作(主要指团队(Team)中协作)和技术 3者关系而不仅仅是去关注那些技术细节5、架构设计
成功和否决定着系统品质好坏架构设计不好而导致交付系统Bug过多无法满足客户非功能性需求等问题从而导致项目取消案例时有发生架构设计不是架构设计师个人事情也不是几天就能完成项工作必须是架构设计师付出大量辛勤劳动后成果其成败往往和组织、主管、项目经理(project manager)支持有着密切关系有关架构设计
点通用窍门技巧1、分层(Layer)规则
这里层是指逻辑上层次(Layer)并非指物理上层次(Tier)目前绝大多数企业级应用系统中都分为 3层即表现层领域层和数据层在对各层次进行划分时主要可以从以下几个方面来考虑:A、每层是个相对独立部分可以作为个整体无需对其它层了解；B、将层次间依赖性降到最低即降低耦合；C、可以从某种程度上替换掉某层而对其它层不会产生过多影响；D层次并不能封闭所有东西假如用户界面上增加了个栏位那么领域层就要增加个数据域数据层就要增加个相应字段同时过多分层可能会对性能造成定影响2、包(package)的间不要产生循环依赖
通常包划分会先按区别逻辑层来划分在层包下面再按功能来划分避免包间循环依赖是个比较通用规则这样规则定有其存在价值和道理的所以这样主要是出于以下原因:A、循环依赖会使分层失去意义；B、循环依赖会带来许多潜在风险如可能会产生嵌套事务(nested transactionJavaEE标准中并不支持这种事务)现象我就曾遇到过这样问题在个项目中事务放在业务逻辑层统控制但由于开发人员忽视了架构中这样原则在持久层
了展现层公用类形成了回圈现象导致了嵌套事务发生3、设计模式
应用在很多人观念里提供设计模式就等同于GOF设计模式其实设计模式是个广泛概念比如需求模式、领域模式、反模式等都属于设计模式模式其实是门工具是人们对于过去解决某类问题经验整理总结所以我们可以在设计活动中应用各种设计模式但是在应用这些模式的前定要先分析清楚问题否则就可能出现“牛头不对马嘴”现象成功
项目总有相似的处失败项目却各有各失败的处好软件Software架构设计必定是成功项目相似的处我们有什么理由不把软件Software架构设计做好了？
最新评论