软件架构介绍

此文介绍软件的架构                                        

什么是软件架构以及为何我们需要它?

就如同其他复杂结构一样，软件必须要建构在一个坚实的基础之上。没有考虑到关键场景，没有针对常见问题的设计，或者没有考虑一些重要决定带来的长期结果，就会将你的软件应用程序置于危险之中。代码没有架构，就如同花园中的常青藤，会变得很难维护，添加新特性也困难。

软件架构是一个技术蓝图，诠释了在优化诸如软件性能，安全性以及可管理性等常见的属性时候系统是如何由子系统（模块）构建的。

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 这样定义架构：

一个程序或计算机系统的软件架构是指系统的一个结构或多个结构，它们组成软件元素，元素的外部可见性，元素间的关系。架构关心公共接口；元素的私有细节——内部实现的细节——不是架构。

架构的目标是识别出影响应用结构的需求。优秀的架构能减低构建一个技术解决方案的业务风险。优秀的设计是足够灵活的，可以应对随时变化的硬件与软件技术，以及用户场景与需求。

软件架构提供了一些益处，包括：

• 更高的生产效率。 结构确定了，那就更容易想已有的软件添加新个性，而且每一处新代码的位置都是事先知道的。

• 更好的代码可维护性。 代码结构可见和已知，那就更容易维护已有的软件，所以也更容易找到 bug 和异常现象。

• 更高的适应性。 软件架构事先考虑到清晰的分离，那就更容易完成诸如换一个前端，添加业务规则引擎等新技术特性。

• 宣扬不可知论。 最后，不过不是必然，软件架构能使你根据你当前的结构看到行业里大肆宣扬和时髦的东西，去适应这些大肆宣扬和时髦的东西。

软件架构模式和风格

客户端/服务端 架构

客 户端/服务端 是由两部分组成的软件架构模型，通过计算机网络——或在同一台计算机上——相互通讯的客户端系统和服务端系统。一个客户端-服务端应用是由客户端和服务端 软件组成的分布式系统。客户端-服务端应用提供了一种分担负载的好方法。客户端进程总是启动一个到服务端的连接，而服务端进程则总是等待来自任何客户端的 请求。客户端-服务端架构有时也角度奥两层架构。

基于组件的架构

基于组件的架构关注于设计的分解，即设计成单独的功能性或逻辑性组件来表示定义明确、包含方法、事件与属性的通信接口。它提供了更高层次的抽象并将问题分解为与组件相关的子问题。

基于组件的架构的首要目的是确保组件的复用性。组件将一个软件元素的功能与行为封装到一个可重用的、独立部署的可执行单元。

下面是用UML 2.0表示的两个组件。负责处理用户订单的checkout组件需要通过CardProcessing组件从用户的信用卡/借记卡中扣费(即后者提供的功能)。

领域驱动设计

领域驱动设计(DDD)是创建满足核心业务目标的高质量软件的方法。它强调领域专家、开发者、UX(用户体验)设计师及其他相关人员间的合作，以创建一个 能反映业务需求的领域模型。这包括通用术语(也称为通用语言)的协商、业务实体的指定及其行为与联系，并以一种能够生成整洁且模块化的实现方法进行组织。

策略领域驱动设计模式及其间的关系

分层架构

分层架构专注于将应用程序中的相关功能组合到不同的层级中，层级间呈现出垂直层叠的结构。每一层中的功能都同一个通用和角色或者职责相关。层级间的通信是 明晰的，而且是松耦合的。将你的应用程序分出层级来非常有助于对关注点分离策略的支持，而这回头就支持了灵活性和可维护性。

消息总线架构

消息总线架构描述了描述了一个使用软件系统的原则，那就是能使用一个或者更多的通信信道来接收和发送消息，那样应用程序无需知道每个信道的特定的细节就能 实现交互。这是一种设计应用程序的风格，采用这种风格之后应用程序间的交互就由公共总线上消息的传递来完成(这种传递经常是异步的) 。消息总线架构最常用的实现不是使用的消息路由，就是发布/订阅模式，并且经常使用一个诸如消息队列这样的消息系统来实现。

N层/3层架构

N层/3层架构描述是将功能大致像分层风格的架构那样分隔成几段，而让每一段都成为可以被放到一个物理上分离的计算机上的层。它们是通过面向组件的方法被发展而来的，一般通信是用的特定于平台的方法，而不是基于消息的方式。

面向对象的架构

面向对象的架构是一种基于责任分解的设计范式，即将系统分解为独立可复用的对象，每个对象包含了与自身相关的数 据与行为。面向对象设计将系统看作一系列相互协作的对象，而不是一组程序或处理指令。对象间相互分离、独立且耦合松散；它们通过接口调用或处理其他对象内 的属性，并通过消息的发送与接收在接口上进行通信。

面向服务的架构(SOA)

面向服务的架构（SOA）是一种用于创建基于服务的使用的体系结构的方法。服务(例如 RESTful Web service)实现了一些小的功能，如生成数据、验证用户或提供简单的分析服务。

SOA 架构的关键是相互独立且松耦合的服务间的互动。SOA 架构实现了服务的复用，因此在升级或需要做其他变动时不需要再从头开始。

洋葱架构

洋葱架构是由 Jeffrey Palermo 提出的，它类似于 Alistair Cockburn 提出的六边形架构(Hexagonal Architecture)。

该架构的提出最初是为了避免在 N 层架构中各层间的依赖关系。它通过将所有基础服务（包括数据库）移出问题域来实现。将此理论实施到 N 层架构意味着要将依赖流反转，从而将业务逻辑独立出来。

这个理论生成了一个新的模型，在这个模型中业务逻辑处于架构的中心，其他层围绕在它周围形成同心环，就像一个洋葱一样。

总结

这是第一个专注于涵盖与软件架构主题相关的系列文章。

我们将很快发布该系列的更多文章，敬请关注。您可以免费订阅此博客以获取每周更新的新文章。

参考

• https://msdn.microsoft.com/en-us/library/ee658098.aspx

• https://msdn.microsoft.com/en-us/library/ee658117.aspx

• https://en.wikipedia.org/wiki/Software_architecture

• http://sanderhoogendoorn.com/blog/index.php/why-do-we-need-software-architecture

• https://simple.wikipedia.org/wiki/Client-server

• http://www.tutorialspoint.com/software_architecture_design/component_based_architecture.htm

• https://archfirst.org/domain-driven-design

• http://www.cs.ccsu.edu/~stan/classes/CS530/Notes14/06-ArchitecturalDesign.html

• http://searchsoa.techtarget.com/definition/service-oriented-architecture

• https://blog.apnic.net/2015/08/18/architecture-at-apnic-the-onion-architecture

• http://www.slideshare.net/kindblad/application-architecture-32607528                                        

License

本文及相关源码与文件受 MIT 协议保护。