软件架构设计

软件架构设计软件架构设计的目的对于外包业务类型的项目，软件架构设计的目的与产品类型的项目有所不同，在这里主要争论外包类型项目的软件架构设计目的

1、为大规模开发供应基础和法律规范，并供应可重用的资产软件系统的大规模开发，必需要有肯定的基础和遵循肯定的法律规范，这既是软件工程本身的要求，也是客户的要求架构设计的过程中可以将一些公共部分抽象提取出来，形成公共类和工具类，以达到重用的目的

2、肯定程度上缩短项目的周期，采用软件架构供应的框架或重用组件，缩短项目开发的周期

3、降低开发和维护的成本，大量的重用和抽象，可以提取出一些开发人员不用关怀的公共部分，这样便可以使开发人员仅仅关注于业务规律的实现，从而削减了很多工作量，提高了开发效率

4、提高产品的质量，好的软件架构设计是产品质量的保证，特殊是对于客户经常提出的非功能性需求的满意软件架构设计的原则软件架构设计必需遵循以下原则

1、满意功能性需求和非功能需求这是一个软件系统最基本的要求，也是架构设计时应当遵循的最基本的原则

2、有用性原则，就像每一个软件系统交付给用户使用时必需有用，能解决用户的问题一样，架构设计也必需有用，否则就会高来高去或过度设计

3、满意复用的要求，最大程度的提高开发人员的工作效率软件架构设计的几种视图我们经常在争论架构设计该做些什么的时候，或是在架构设计评审的会议上，会提出各种各样的问题，例如开发人员该如何纪录Log事务如何掌握？怎样才能提高我们的开发人员的工作效率，即在单位时间内更有品质的完成更多的功能？怎样满意客户的非功能性需求？怎样让生产环境的平台管理人员更好的维护系统？上面这些问题，实际上是软件系统的不同的干系人站在不同的角度上提出的问题，要回答上面这些问题，我们就得从不同的视角来看待软件架构设计这项工作

1、规律架构视角，从系统用户的角度考虑问题，设计出来的软件架构能够满意业务规律的需求，能够处理现在越来越简单的业务规律需求

2、开发架构视角，从系统开发人员的角度来考虑问题，设计的架构要易于理解，易于开发，易于单元测试，最好做到让开发人员可以用最少的代码行数完胜利能的开发

3、运行架构视角，从系统运行时的质量需求考虑问题，特殊关注于系统的非功能需求，客户经常都会要求我们系统的功能画面的最长响应时间不超过4秒，能满意2000个用户同时在线使用，基于角色的系统资源的平安掌握等

4、物理架构视角，关注系统安装和部署在什么样的环境上，例如现在最流行的企业应用服务解决方案IBMHttpServer+WebSphereApplicationServer+DB2WebLogic+Oracle等

5、数据架构视角，如今我们开发的各类系统，如MISERPSAP基本上都是对各类数据的操作，把一堆不太好懂的数据呈现成用户简洁看懂的数据，自动处理各类数据的运算等，所以数据的长久化是特别重要的一件事情

1、分析需求和理解业务模型（或领域建模），并选定关键Usecase0软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必需从不同的视角和级别去全面的熟悉需求并分析需求理解业务模型实践表明，经常被我们忽视的非功能性需求经常会导致整个项目失败理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用♦探究简单问题，弄清领域学问MartinFowler曾经说过，他采纳面对对象方法最大的好处就是它有助于解决更为简单的问题领域建模本身作为帮助思维的工具，关心我们将留意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深化地，系统的对需求进行分析和熟悉领域建模往往是一个从模糊到清晰，从零散到系统的过程♦打算功能范围，影响可扩展性任何模型都是对现实世界某种程序的抽象，这种抽象就会忽视某一些东西，例如忽视对象的属性和对象间的关系，而这些忽视往往都是带有肯定的目的性的，这种忽视就打算了功能的范围模型揭示了各种功能背后的结构，假如说定义功能相当于拍照片的话，那么领域建模就相当于做透视，更加关注问题领域的内在结构，相当于对问题领域进行了肯定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在肯定程度上支持将来可能消失的新需求，体现良好的可扩展性♦供应沟通基础，促进有效沟通领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通供应了便利当然，有时候文字在描述某些特定领域的问题时可能更适合，可以敏捷运用在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处虽然我们总是期望架构设计师能全面把握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对全部需求进行深化分析，所以我们的策略就是把好钢用在刀刃上，即把大部分时间和精力花在对打算架构最重要的关键需求上在选择关键需求时要留意高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求在《RUP实践者指南》一书中向我们叙述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能B必需被实现的功能，即假如这些功能不被实现，则开发出来的软件就失去了价值，C.掩盖了系统架构的一些方面，但没有被其他重要的Usecase掩盖到的功能

2、分别从各个视角来考虑软件架构的方方面面软件的架构设计必需考虑到各方面，依据前期工作确立的领域模型，关键需求，系统约束等进行设计，必需从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题比如说，假如我们的运行架构采纳Cluster方式时，就必需当心Cache和Session等的使用；假如我们的业务规律要求我们要操作多个数据库时就要考虑采纳支持二阶段事务提交的方式只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的至于每一个视图中，我们应当设计到什么细节这一问题，实际上与整个项目的过程定义有关例如，假如我们有特地支配数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但假如没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系

3、解决技术面的重点问题和难题在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论学问和丰富的实践阅历支撑的工作例如，我们如何提高整个系统的性能？如何能很好的导出极其简单的中国式报表（一般比西方我国产出的报表要简单很多，而且很多开源的BI类的框架并不能完全解决问题）？当遇到的确是很困难的问题，可以去百度一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题争论会议，采纳脑力激荡的方法试着找找答案，这样才能提高工作的效率

4、召开架构设计评审会议进行同行评审架构设计评审是极其重要的一环，我曾将其形容为七种武器”中的离别钩，就是由于在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以肯定要虚心接受，并做好纪录，正所谓良药苦口利于病，忠言逆耳利于行”在评审会议之前，我们要完成很多预备工作，最好是能预备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会掌握会议的进度，提高会议的效率

5、针对关键Usecase在设计的架构上实现功能来验证架构对于架构设计的验证也是一项特别重要的工作，其验证技术有很多种，在我们公司通常会采纳Sample的形式，即XP中所说的迭代0RUP中所说的切片这样做的好处是既可以从实际的产品角度动身来有效的验证架构是否满意要求，又可以比抛弃型原型验证技术节约成本这个Sample绝不是我们在解决架构设计中的问题时拿来做试验的一些代码的拼凑，而是完整的实现某一关键Usecase的符合架构设计和一系列法律规范的可交付的代码及相关文档同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简洁的修改即可

6、交付给客户Review0这一环节，在很多公司可能并不存在，由于他们的软件架构并不肯定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用通常，我们的架构得到客户的认可后，便可进入大规模的开发在交付给客户Review时，通常可能会以会议的形式进行Review所以我们可以参照评审会议时好的做法来召开会议，在这里就不再冗述软件架构设计的常见误区及解决方法

1、架构设计的经常会高来高去、所谓高来高去，实际上就是我们的架构设计仅停留在模型阶段，但也绝不是产生第一支样例程式

2、架构设计时经常会在某些方面过度设计Overengineeringo为了一些根本不会发生的变化而进行一系列简单的设计，这样的设计就叫过度设计，往往会带来资源的铺张并且会增加开发的工作量或难度虽然我们必需考虑到系统的扩展性，可维护性等，但切忌过度设计有时候或许你并不能推断出哪些设计是过度设计，此时你可以请教你的PM让他站在整个项目的高度来帮你决策一下

3、架构（Architecture）不是框架（Framework）也不是简洁的将几种框架或技术的组合，框架本身也是有架构的框架一般是针对于某一方面或领域的重用性和可扩展性特别好的半成品，我们可以用一句较为经典的话来总结框架是软件，架构不是软件，框架是一种特殊的软件我们在工作中通过将很多方面的可重用的工具类，公共类，基础类等抽象出来，即可形成一些可重用的框架

4、架构设计绝不是新技术展现平台，合适的技术才是对于项目有利的技术，必需考虑到开发人员的力量和维护人员的力量作为一名架构设计师应当更多的考虑如何平衡业务需求，织织运作（主要指团队中的协作）和技术三者的关系，而不仅仅是去关注那些技术细节

5、架构设计的胜利与拒绝定着系统品质的好坏，由于架构设计不好而导致交付的系统Bug过多，无法满意客户非功能性需求等问题，从而导致项目取消的案例时有发生架构设计不是架构设计师一个人的事情，也不是几天就能完成的一项工作，必需是架构设计师付出大量辛勤劳动后的成果，其成败往往与组织、主管、项目经理的支持有着亲密的关系关于架构设计的一点通用技巧

1、分层（Layer）规章这里的层是指规律上的层次（Layer）并非指物理上的层次（Tier%目前的绝大多数的企业级应用系统中都分为三层，即表现层，领域层和数据层在对各层次进行划分时，主要可以从以下几个方面来考虑A、每一层是一个相对独立的部分，可以作为一个整体，无需对其它层了解；B、将层次间的依靠性降到最低，即降低耦合；C、可以从某种程度上替换掉某一层，而对其它层不会产生过多的影响；D层次并不能封闭全部的东西，假如用户界面上增加了一个栏位，那么领域层就要增加一个数据域，数据层就要增加一个相应的字段同时，过多的分层可能会对性能造成肯定的影响

2、包（package）之间不要产生循环依靠通常包的划分会先按不同的规律层来划分，在层的包下面再按功能来划分避开包间的循环依靠是一个比较通用的规章，这样的规章肯定有其存在的价值和道理，之所以这样主要是出于以下缘由A、循环依靠会使分层失去意义；B、循环依靠会带来很多潜在的风险，如可能会产生嵌套事务（nestedtransactionJavaEE标准中并不支持这种事务）的现象，我就曾遇到过这样的问题，在一个项目中，事务放在业务规律层统一掌握，但由于开发人员忽视了架构中这样的原则，在长久层调用了呈现层的公用类，形成了回圈的现象，导致了嵌套事务的发生

3、设计模式的应用在很多人的观念里，供应设计模式就等同于GOF的设计模式其实设计模式是个广泛的概念，比如需求模式、领域模式、反模式等都属于设计模式模式其实是一门工具，是人们对于过去解决某一类问题的阅历总结，所以我们可以在设计活动中应用各种设计模式，但是在应用这些模式之前肯定要先分析清晰问题，否则就可能消失牛头不对马嘴”的现象胜利的项目总有相像之处，失败的项目却各有各的失败之处好的软件架构设计必定是胜利项目的相像之处，我们有什么理由不把软件架构设计做好了？。