软件架构
对于许多开发者而言，在适当的地方没有正式的架构就开始敲代码是一件极为普通的事情。为什么要有架构呢？
为什么构建软件架构
众多的利益相关者
软件系统必须迎合利益相关者的变化，例如业务经理，主人，用户和操作者。这些利益相关者都有对于系统的期望概念，平衡这些意图，证明它们是如何解决的是设计系统的一部分。这意味着架构牵涉处理意图的变化和利益关系，这里面牵涉各种学问。
关系的分离
对于已制定的架构去减少复杂度是驱使设计分离关系。架构文本展示了所有利益相关者关心的事情通过模型化和从关联变化的利益关系关心的事的点子上分离地描述架构。这些分离描述被称之为架构视图
质量驱动
古典的架构设计方法通过要求函数和通过系统的数据流来驱动，但是当前的视野是软件系统的架构更加接近相关它的品质属性例如容错，向后兼容，可扩展性，可利用性，维护性，可用性，安全性等等。利益相关者关心的事情常在这些品质属性上呗转换到要求，这被称之为非功能性要求，额外的功能要求，行为要求，品质属性要求等
再发的循环
像建筑建筑一样，软件架构学科有一个发达的标准方式去实现再发的关心的事。这个标准方式被以在抽象的变化等级内的变化的名字命名。一般的术语对于再发的解决方案是架构化的风格，引用架构，架构样式
概念上的完整
一个被fred介绍的术语去表示一个软件系统呈现一个它应该干什么，如何做的全部的视角。这个视角应该通过它的实现被分离。
这就是为什么要设计软件架构？尤其是一个大型项目，你必须设计它的架构，否则当在不停扩展它的功能时候，你会发现后面完全做不下去了，真正好的架构应该是高内聚，低耦合。
1，分层的模式
最为普遍的架构样式就是分层的模式，在其他方面闻名的N层样式。这个样式对于许多Java应用而言是事实上的标准，因此被许多架构师，设计者，开发者广为流传。分层的模式密切地关联着传统的IT团体和组织，这对于许多商业应用开发而言是一个自然的选择
1.1 模式描述
在分层的架构模式内的小组件被以水平式的方式组织。每层在应用内呈现特定的角色。入呈现逻辑或业务逻辑。尽管分层架构的模式是不指定层的类型和数量。大多数分层的架构组成了四个标准层次：展示，业务，持久和数据库。在有些事件中，业务层和持久层被结合进入一个单一的业务层。通常地持久逻辑在业务层小组件内插入。因此，较小的应用只有三层，较大的复杂商业应用则包含5或以上的层。
分层架构模式的每层都有一个特定的 角色和责任，这叫分工，好区分责任，如果后续出错也好排查，大家都爱吃大锅饭，因为不担责任，但慢慢地大锅饭最后无法开锅了。例如，一个展示层对于处理所有用户交互和浏览器交互逻辑（然而一个业务层对于这行特定的关联请求的特定业务有责任）。在架构中的每层都围绕需要做来满足通常的业务请求的工作来建立一个抽象、例如展示层不必知道或担心如何得到用户数据；它仅仅需要以常用的格式来在屏幕上呈现信息。类似地，业务层不必关心关于如何形成用户数据来展示在屏幕上或甚至用户数据从哪里来；它只需要从持久层得到数据， 执行业务逻辑与数据（例如，减值和合计数据），把这些信息向上传递给展示层。
分层架构模式的一个强大的特性便是小组件之间的分离问题。在特定层内的小组件仅仅处理对于那个层的特定逻辑，例如在展示层中的小组件仅仅处理展示逻辑，反之 组件驻留在业务层只处理业务逻辑。这种类型的组件分类便于模型到你的架构,建立有效的角色和责任,也便于开发、测试、管理和维护应用程序使用这个架构模式由于定义良好的组件接口和有限的组件范围。
1.2 关键性概念
如图所示
在架构中的每一层都被标记为关闭，这是一个非常重要的概念。一个关闭的层意味着作为一个请求从层到层，它必须经过层下面去下一层的下面。例如请求来自表示层必须首先通过业务层和持久层，最后到达数据库层。
为什么不允许表示层直接存取到要么持久层要么数据库层呢？毕竟，直接数据库从表示层存取比经过不必要层的一串去检索或保存数据库信息更加快？这个问题的答案就在于分层的模式的关键概念-层隔离。
层隔离的概念意味着在架构中的一层内的变化通常不能影响或感染在其他层的组件。这个变化对于那个层内的组件是被隔离的。可能另外的关联层（例如一个包含SQL的持久层）。如果你运行表示层直接存取到持久层，然后更改SQL在持久层会在业务层和表示层之间有影响，从而产生一个非常紧密耦合的应用程序的组件之间的相互依赖关系，这种类型的架构就变得非常困难并且敖贵。隔离层的概念也意味着每一个层是独立于其它层，从而有很少或者没有其他层内部工作的知识架构。考虑一个大型展示框架重构工作从JSF JSF（如假设合同，模型）表示层和业务层之间使用保持不变，不影响业务层的重构和保持完全独立类型的用户界面表示层所采用的框架。
虽然封闭层促进层体系结构内的隔离，从而有助于隔离变化，有些时候对于某些层的开放是有意义的。例如，假设您要添加一个共性服务层架构 包含服务组件，访问组件在业务层（如数据和字符串使用程序类或审计和日积类）。创建一个服务层通常是一个比较好的主意在这样的情况下，因为架构限制访问共性服务业务层（而不是表示层）。没有一个单独的层，没有什么架构限制表示层访问这些公共服务，很难控制这个访问限制。在这个示例中，新的业务服务层可能驻留在一层一层表明组件在这个服务不是从表示层访问。业务层现在需要通过服务层持久层，这一点意义都没有，分层架构是一个古老的问题，解决了在架构内创建开放的层
如下面的插图所示，这个事件中的服务层被标记为开放，意味着请求被允许去绕开开放的层然后直接进入它下面的层。在下面的例子中，自从服务层开放，业务层被允许绕开它然后直接进入持久层，这完全讲得通。
影响开放的概念和关闭的层帮助在架构层和请求留之间定义了关系，并且在架构中用必要的信息去理解变化层存取限制去提供给设计者和开发者。带文件的失败或者在架构中强档的交互式开放和关闭的通常紧密联系，易碎的架构是非常难与测试，维护和部署。
1.3 模式例子
举例说明分层的架构如何工作，考虑一个从业务层用户到重新得到用户信息、
例子中消费者信息由2部分组成，消费者数据和订单数据
用户屏幕对于接受请求并显示用户消息有责任，它不知道数据来自哪里，如何检索，甚至多少数据库被检索来得到数据。一旦用户屏幕接受了一个请求对于通常的个人去得到用户消息，它然后转发那个请求到用户代理模型上。这个模型对于这点在业务层
处理那个请求的哪个模型是有责任的，并且然后到达那个模组，数据需要什么。消费者对象在业务层对于合计通过业务请求需要的所有信息是有效的，这个模型召唤到用户dao模型（在持久层内）去得到用户数据，并且order dao模型去得到订单信息。这些模型在转换执行SQL语句去检索正确响应数据然后传送它返回到客户对象。一旦客户对象重新得到数据，它合计这些数据然后传送这些信息到用户代理门，然后传送那个数据到用户屏幕最后展示给了用户查看。
2，分层的考虑
分层的结构模式是一个坚实的通用模式，使它有一个很好的起点对于大多数应用程序，尤其是当你不确定体系结构模式是最适合您的应用程序，然而当选择此模式时，有几个事情要从体系结构的角度去考虑。
1，架构抗反模式，此模式描述的情况通过多层体系勾结的简单请求流直通处理很少或根本没有逻辑执行在每个层。例如，假设表示层响应来自用户的请求来检索客户数据。表示层将请求传递到业务层，它将请求传递到持久层，然后进行简单的SQL调用来检索客户数据到数据库层，然后通过追溯数据堆栈没有额外处理或逻辑聚合，计算或转换数据。每一个分层结构将至少有一些场景，落入抗反模式架构，然而，关键是分析调入这个类别的百分比。80-20规则通常是一个很好的实践，遵循它来确定你是否在经历架构抗反模式。电信的有大约20%的请求一样简单直通处理，80% 请求与请求相关的一些业务逻辑，然而如果你发现这个比例逆转，大部分简单直通处理你的请求，你可能想要考虑的一些架构层开放，这将是更难控制改变由于缺乏层隔离。分层架构模式的另外一个考虑是，它往往借向独立应用程序本身，即使你把表示层和业务层分割成单独的部署但愿，虽然这可能不是一个问题，对于某些应用程序而言，它存在潜在问题的部署，可靠性，性能，可扩展性
模式分析
全敏捷性：它是一种能力去快速响应到一个持续改变的环境，当改变能通过隔离层特性被隔离，它仍然是累赘的并且耗时的在这个架构内做改变因为大多数实现的整体性以及紧密耦合的组件以这样的模式通常被发现，因此它的全敏捷性低。
易部署：基于你要如何实现这个模式，部署会成为一个问题，这主要是针对更大的应用程序。一个到一个组件的小的变化能要求一个全部应用的一个再部署。结果在于部署需要被计划，被安排，被执行（在非高峰时间或是周末），基于此，这个模式不容易借向持续交付管道本身，进一步减少总评部署。因此部署性低。
可扩展性：由于紧密耦合的趋势和整体的实现，应用程序构建使用这个模式通常很难，你可以扩展一个分层架构层分割到不同的物理部署或整个应用程序赋值到多个节点，但总体粒度太广泛因而使得其代价昂贵，因为可扩展性低。
可开发性：易于开发得到相对高的分数，主要是因为这种模式是如此出名，不过过于复杂的实现。因为大多数公司通过分离技能开发应用程序层，这个模式就变成了一个自然的选择。公司之间的联系沟通和组织机构和软件开发方式概述了什么是被称为康威定律，关于这个迷人的相关性你可以谷歌conway法则来获取更多的信息。
可测试性：因为组件属于特定的层，其他层能被失效或被存根，使得这个模式相对容易测试。
性能：当它是真的一些层架构师性能可以，这个模式不借向高性能应用归于必须经历结构的多层去实现一个业务请求，因此性能低。
