标签:
此文介绍软件的架构
什么是软件架构以及为何我们需要它?就如同其他复杂结构一样,软件必须要建构在一个坚实的基础之上。没有考虑到关键场景,没有针对常见问题的设计,或者没有考虑一些重要决定带来的长期结果,就会将你的软件应用程序置于危险之中。代码没有架构,就如同花园中的常青藤,会变得很难维护,添加新特性也困难。 软件架构是一个技术蓝图,诠释了在优化诸如软件性能,安全性以及可管理性等常见的属性时候系统是如何由子系统(模块)构建的。 Philippe Kruchten, Grady Booch, Kurt Bittner以及Rich Reitman在Mary Shaw and David Garlan (Shaw and Garlan 1996)的成果基础上延伸并提炼出了对软件架构的定义。他们是这么定义的:
|
在Patterns of Enterprise Application Architecture 中,Martin Fowler 概括了一些解释架构是经常提到的主题。他认为这些主题是:
在 Software Architecture in Practice (2nd edition )中,Bass, Clements 和 Kazman 这样定义架构:
架构的目标是识别出影响应用结构的需求。优秀的架构能减低构建一个技术解决方案的业务风险。优秀的设计是足够灵活的,可以应对随时变化的硬件与软件技术,以及用户场景与需求。 |
软件架构提供了一些益处,包括:
软件架构模式和风格客户端/服务端 架构客户端/服务端 是由两部分组成的软件架构模型,通过计算机网络——或在同一台计算机上——相互通讯的客户端系统和服务端系统。一个客户端-服务端应用是由客户端和服务端软件组成的分布式系统。客户端-服务端应用提供了一种分担负载的好方法。客户端进程总是启动一个到服务端的连接,而服务端进程则总是等待来自任何客户端的请求。客户端-服务端架构有时也角度奥两层架构。 |
基于组件的架构基于组件的架构关注于设计的分解,即设计成单独的功能性或逻辑性组件来表示定义明确、包含方法、事件与属性的通信接口。它提供了更高层次的抽象并将问题分解为与组件相关的子问题。 基于组件的架构的首要目的是确保组件的复用性。组件将一个软件元素的功能与行为封装到一个可重用的、独立部署的可执行单元。 下面是用UML 2.0表示的两个组件。负责处理用户订单的checkout组件需要通过CardProcessing组件从用户的信用卡/借记卡中扣费(即后者提供的功能)。 领域驱动设计领域驱动设计(DDD)是创建满足核心业务目标的高质量软件的方法。它强调领域专家、开发者、UX(用户体验)设计师及其他相关人员间的合作,以创建一个能反映业务需求的领域模型。这包括通用术语(也称为通用语言)的协商、业务实体的指定及其行为与联系,并以一种能够生成整洁且模块化的实现方法进行组织。 策略领域驱动设计模式及其间的关系 |
分层架构分层架构专注于将应用程序中的相关功能组合到不同的层级中,层级间呈现出垂直层叠的结构。每一层中的功能都同一个通用和角色或者职责相关。层级间的通信是明晰的,而且是松耦合的。将你的应用程序分出层级来非常有助于对关注点分离策略的支持,而这回头就支持了灵活性和可维护性。 消息总线架构消息总线架构描述了描述了一个使用软件系统的原则,那就是能使用一个或者更多的通信信道来接收和发送消息,那样应用程序无需知道每个信道的特定的细节就能实现交互。这是一种设计应用程序的风格,采用这种风格之后应用程序间的交互就由公共总线上消息的传递来完成(这种传递经常是异步的) 。消息总线架构最常用的实现不是使用的消息路由,就是发布/订阅模式,并且经常使用一个诸如消息队列这样的消息系统来实现。 N层/3层架构N层/3层架构描述是将功能大致像分层风格的架构那样分隔成几段,而让每一段都成为可以被放到一个物理上分离的计算机上的层。它们是通过面向组件的方法被发展而来的,一般通信是用的特定于平台的方法,而不是基于消息的方式。 |
洋葱架构洋葱架构是由 Jeffrey Palermo 提出的,它类似于 Alistair Cockburn 提出的六边形架构(Hexagonal Architecture)。 该架构的提出最初是为了避免在 N 层架构中各层间的依赖关系。它通过将所有基础服务(包括数据库)移出问题域来实现。将此理论实施到 N 层架构意味着要将依赖流反转,从而将业务逻辑独立出来。 这个理论生成了一个新的模型,在这个模型中业务逻辑处于架构的中心,其他层围绕在它周围形成同心环,就像一个洋葱一样。 |
标签:
原文地址:http://www.cnblogs.com/b8899/p/5104959.html