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