Application Architecture Guide 2.0 学习笔记(一)前言 - General

最近学习来自于 Microsoft patterns & practices Developer Center  的一篇关于应用程序架构指导的文章:

Application Architecture Guide 2.0,个人觉得还是很实用的,做了一些简单的笔记。 

Objectives Of The Guide

  • 学习典型的应用程序架构设计方法;
  • 学习你可以构建的不同类型的应用;
  • 了解在设计的时候必须考虑的关键因素;
  • 学习分层的应用程序设计方法;
  • 了解影会影响到一个应用程序最后的成功与接受度的质量指标;

General

      下面的guidelines 会帮助你理解一些在设计时会用到的基本技术方法。把这些 guidelines  作为一个起点:关于如何去设计你的应用程序,如何去构造你的应用,如何去分层和如何去评估你的设计。

 

(后面的不翻译了。。中午贴了很长一段,都注释了,点了保存为草稿,结果居然都没了-。-)

 

• How to design your architecture 【如何设计架构】  

 
First, determine the objectives of your architectural design(首先定义设计目标), which will help you to focus on solving the right problems(专注解决正确的问题). Then identify the key scenarios(关键应用场景) or use cases (用例)that are most critical(决定性的) from your application’s perspective and that have maximum impact(最影响的) on the architecture. The use cases will help you to identify critical problem areas and will also help in evaluating and reviewing the architecture(有助于识别关键领域并帮助评估和审查架构). To achieve the architectural objectives, identify the application type(确定应用类型), deployment architecture(部署架构), architecture style(架构风格), and related technologies(相关技术) in view of the identified key scenarios(考虑到已识别的关键应用场景). While doing so, ensure that you take into account any infrastructural and organizational constraints(这样做的时候,确信要考虑到基础设施与组织上的约束). Identify the quality attributes (performance, security, etc.) and cross-cutting concerns (exception handling, auditing and logging, and so on) that are important from an application perspective(确定对于应用程序很重要的质量属性,比如说性能、安全等,以及跨域的关注点,例如异常处理、审核与日志记录等等), to make sure that the architecture adheres to their requirements and objectives(已确保架构能够紧跟需求与目标). Finally, define the architecture solution and review/validate it against the key scenarios you identified(最后,确定架构方案并根据关键应用场景进行审查/验证).

 

For more information, see Chapter 4, “Designing your Architecture.”

 

• How to choose a deployment topology(如何选择部署架构)


When you design your application architecture, you must take into account corporate policies and procedures(必须考虑企业政策与程序), together with the infrastructure on which you plan to deploy your application(还有计划部署应用的基础设施). If the target environment is rigid, your application design must reflect the restrictions that exist in that rigid environment(如果目标环境不可改变,应用设计必须反映目标环境中的约束). Your application design must also take into account quality attributes such as performance, security, and maintainability(应用设计还必须考虑到一些质量指标,例如性能、安全与维护性). Sometimes you must make design tradeoffs because of protocol restrictions and network topologies(有的时候必须做出妥协,因为协议限制和网络拓扑). Identify the requirements and constraints that exist between application architecture and infrastructure architecture early in the development process(要尽早的在部署过程中确定应用架构与基础设施的要求与约束). Use a layered design that separates presentation, business, and data access logic, to improve scalability and maintainability(使用分层设计来分离表示、业务与数据访问,以提高扩展性与维护性). To avoid unnecessary remote calls and additional network latency, stay in the same process where possible(避免不惜要的远程调用和网络延迟). If you do need a distributed architecture(如果确实需要一个分布式结构), consider the implications of remote communication when you design your interfaces(设计的时候要考虑到远程通信的影响). For example, you
might need a distributed architecture because security policy prevents you from running business logic on your Web server, or you might need a distributed architecture because you need to share business logic with other applications, Try to reduce round trips and the amount of traffic that you send over the network(举例,因为安全策略不允许在Web服务器上运行业务逻辑,你可能就需要一个分布式架构,或者因为需要与其他应用共享业务逻辑而需要使用分布式架构。要尝试减少通信的来回次数和网络上的数据量).


For more information, see Chapter 5, “Deployment Patterns.”


• How to structure your application(如何构建你的应用)


Start at the highest level of abstraction and begin by grouping your application functionality into logical layers(从最抽象层开始,将应用程序的功能组织到逻辑层). Understand the available deployment strategies for the physical structure and tiers(了解对于物理结构与层可用的部署策略), and identify how the logical layers will map to the physical tiers(明确如何将逻辑层映射到物理层). Identify communication strategy and the protocols that can be used for communication between the layers and tiers in your application(明确可用在层之间的通信策略与协议). Define interfaces for the layers(为层定义接口), the information that will be communicated between layers(层之间通信的信息), and the form of that communication(通信的形式).


For more information, see Chapter 3, “Architecture and Design Guidelines.”


• How to decide on your layering strategy(如何确定分层策略)


When grouping the components in a layer, make sure that the components depend only on components in the same layer or components in a lower layer(层中的组件只依赖于本层或者下层的组件). Use loose coupling between layers(层之间要实现松耦合). Avoid any circular dependencies between layers(避免循环依赖). Use only the layers that are required and that are relevant to your scenario(只适用应用场景中需要的和相关的层). For example, if your application does not have a user interface (UI), you will not require a presentation layer, but only a programmatic (service) interface(举例:如果应用不要使用UI,就不需要表示层,只需要一个服务接口). If your application has minimal or no business logic (for example, a reporting application), you might not require a business layer(如果应用只有很少的或者没有业务逻辑,就不需要业务逻辑层). If your business logic is not shared by other applications, or is not located on a remote tier, you might not require a service layer(如果你的业务逻辑需要与其他应用共享、或者部署在远程物理层上,可能就需要一个服务层). If your application does not use an external data source, you might not require a data access layer(如果你的应用没有外部数据源,就不需要数据访问层).


For more information, see Chapter 9, “Layers and Tiers.”


• How to perform architecture and design reviews(如何实施架构与设计审查)


Identify the architecture objectives and key scenarios for your applications that have the greatest impact on the application architecture(识别最影响应用架构的关键应用场景与架构目标). Establish design and architecture standards for your application(建立架构标准); use these standards to perform design and architecture inspections(使用这些标准检查架构), using a question-driven(问题驱动) approach with respect to architecture objectives(架构目标), infrastructure(基础设施) and organizational constraints(组织约束), performance(性能), and security goals(安全目标), to focus your efforts. Use the key scenarios identified for scenario-based evaluations(使用已识别的应用场景来做基于场景的评估), such as Software Architecture Analysis Method (SAAM), Architecture Tradeoff Analysis Method (ATAM), and so on.(SAAM与ATAM,去google吧)

 

For more information, see Chapter 4, “Designing Your Architecture.” 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值