代码改变世界

NET 应用架构指导 V2 学习笔记（七） 软件架构和设计方法

2010-05-27 07:23  Virus-BeautyCode  阅读(2245)  评论(1)  编辑  收藏  举报

　　本篇详细介绍架构的步骤

　　1、确定架构的目标

　　架构的目标就是你的结构和设计过程的目的和限制，练习的范围，帮助你决定什么时候算是完成了。在你确定架构的目标的时候，可以参考下面的几个关键点：

　　首先确定架构的目的。你花在架构和设计的每一个阶段的总时间，将会依赖于这些目的。例如：你是否建立原型？是否测试潜在的路径？是否为一个新的应用已经开始长期的架构过程？

　　确定谁将会消费你的架构。确定你的架构是否会被其他架构使用，对于开发者、测试者、操作员、管理者是否可以获得？考虑你的听众的需要和经验，似的你的架构更容易被他们理解。

　　确定你的限制。了解你的技术选型和限制，使用限制，部署限制。在开始就明确你的限制，以便在后面开发的过程中不会浪费时间，和碰到令人奇怪的问题。

　　范围和时间

　　以架构的高层目标为基础，你可以确定花费在每一次架构行为上面的时间。例如：原型可能只需要几天来设计，一个完整的、详细的复杂系统的架构可能需要几个月来设计（需要迭代好多次的架构和设计）。使用你理解的架构目标确定花费在每一个步骤的时间和精力，计算可能的将来的产出结果。清晰的定义架构的目的和优先级。目的可能包含下面的内容：

  • 　　建立一个完整的应用设计。
  • 　　建立原型。
  • 　　确定关键的技术风险。
  • 　　测试潜在的可能性。
  • 　　建立共享的模型，方便理解系统。

　　在设计上，每一次都会有不同的重点，完成的时间也会有变化。例如：如果你想要确定你的认证架构的风险的话，你将会在认证的方案，认证架构的限制条件，可能选择的认证技术上花费大量的时间和精力。但是，如果你处在为一个应用考虑完整架构的开始阶段的话，验证架构只是众多重点中的一部分。

　　一些架构行为的例子是建立在原型基础上的，通过原型来获取反馈。通过原型验证架构的合理性，通过原型细化架构。

　　2、关键的场景

　　在设计和架构的上下文环境，用例用来描述系统和一个或者多个执行者（一个用户，也可能是一个系统）之间的交互行为。一个场景集中描述用户和系统的交互行为，目的是确定多个关键的场景，来帮助你的在架构的时候做决定。目的是在用户，业务，系统目标之间达到平衡。

　　重要的架构用例

　　结构化的重要用例在设计中会对很多方面产生影响。这些用例对于成功的应用尤其重要。他们对于已经部署的应用也很重要，他们必须被足够的试验，来帮助评估架构。包括下面的用例：

  • 　　关键的业务。和其他功能相比，这些用例对于用户有很高的使用级别，是特别重要的，有很高的风险。
  • 　　高影响的。例如：Create,Read,Update,Delete(CRUD)操作的安全性。

　　3、应用概述

　　对于应用达到什么要求，什么时候完成，应该有一个概述。这个概述使得你的架构更加明确，连接真实世界的限制和精确性。一个应用概述应该包括下面的部分：

  • 　　确定应用的类型。首先，确定你的应用是什么类型的，是一个移动应用、富客户端应用、富Internet应用、服务、web应用，还是这些应用的综合。
  • 　　确定部署的限制条件。当你设计应用的时候，一定要把相关的政策、法规，基础设置考虑进去。如果现有环境是不灵活的、固定的，你的设计一定要考虑环境的限制。你的应用还要加入QOS，例如：安全和可靠性。有些时候要需要考虑协议限制和网络限制。
  • 　　确定重要的架构风格。确定在设计中使用的架构风格。
  • 　　考虑相关的技术。

　　相关技术：

  • 　　Mobile Application移动应用，面向手持设备的应用。
  • 　　Rich Client Application富客户端应用，例如：WPF等，客户端具有丰富表现能力的应用。
  • 　　Rich Internet Client Application富internet应用，在原有浏览器的基础上， 增加客户端的交互性，例如：Silverlight，ajax等等。
  • 　　Web Application，典型的web应用。　　
  • 　　Service Application服务应用，以提供服务为目的的应用。webservice，Wcf等。

　　白板化你的架构

　　使用白板描述你的架构是很重要的。通过白板，或者其他形式共享你的架构，方便开始讨论。如果可以提供一个清晰的图例的话，别人会更容易理解你的架构，你也更容易讲清楚里面的细节。

　　

 

　　4、关键的问题

　　潜在的问题包括：新技术，关键的业务需求。例如：第三方的服务客户替换吗？可以支持一种新的客户端类型吗？可以适应业务规则的变化吗？引入新的技术可以吗？

　　质量指标

  • 　　系统质量。整体来看，系统的质量，例如可测试性。
  • 　　运行质量。系统运行的时候直接表现出来的质量问题，例如：性能、可管理性、可靠性、扩展性、安全性。
  • 　　设计质量。例如：灵活性、可维护性、重用性。
  • 　　用户质量。系统的可用性。

　　　跨越多个层次的关注点：

  • 　　认证和授权。
  • 　　缓存。
  • 　　通信
  • 　　配置管理
  • 　　异常管理
  • 　　日志和性能指标显示
  • 　　验证

　　5、候选解决方案

　　在定义了关键问题之后，你可以建立一个架构的基线版本，然后开始细化建立一个满足需求的架构候选方案。随着架构的深入，你会遇到新的需求和发现新的问题，然后再次验证你的候选方案，通过不断的迭代来改进架构设计。

　　在测试一个新的候选方案的时候，可以从下面的问题来考虑：

  • 　　当前架构是否没有引入新的风险？
  • 　　和前一个架构相比，是否缓解了已知的风险？
  • 　　架构满足额外的需求了吗？
  • 　　架构是否满足了重要的用例？
  • 　　架构是否满足质量指标?
  • 　　架构是否满足了额外的跨层关注点？

 

　　未完待续。。。。。。。。。。。。。。。。。。。

　　P43