分层架构中的每一层都着特定的角色和职能。举个例子，展示层卖力处理所有的界面展示以及交互逻辑，业务层卖力处理要求对应的业务。架构里的层次是详细事情的高度抽象，它们都是为了实现某种特定的业务要求。比如说展示层并不须要关心若何得到用户数据，它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式，也不关心这些用户数据从哪里来。它只须要从持久层得到数据，实行与数据有关的相应业务逻辑，然后把这些信息通报给展示层。
分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑。多亏了组件分离，让我们更随意马虎布局有效的角色和强力的模型。这样运用变的更好开拓，测试，管理和掩护。
关键观点把稳表1-2中每一层都是封闭的。这是分层架构中非常主要的特点。这意味request必须一层一层的通报。举个例子，从展示层通报来的要求首先会通报到业务层，然后通报到持久层，末了才通报到数据层。
那么为什么不许可展示层直接访问数据层呢。如果只是得到以及读取数据，展示层直接访问数据层，比穿过一层一层来得到数据来的快多了。这涉及到一个观点:层隔离。
层隔离便是说架构中的某一层的改变不会影响到其他层:这些变革的影响范围限于当前层次。如果展示层能够直接访问持久层了，如果持久层中的SQL变革了，这对业务层和展示层都有一定的影响。这只会让运用变得紧耦合，组件之间相互依赖。这种架构会非常的难以掩护。
从其余一个方面来说，分层隔离使得层与层之间都是相互独立的，架构中的每一层的相互理解都很少。为相识释这个观点的牛逼之处，想象一个超级重构，把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持同等，业务层不会受到重构的影响，它和展示层所利用的界面架构完备独立。
然而封闭的架构层次也有不便之处，有时候也该当开放某一层。如果想往包含了一些由业务层的组件调用的普通做事组件的架构中添加一个分享做事层。在这个例子里，新建一个做事层常日是一个好主张，由于从架构上来说，它限定了分享做事访问业务层(也不许可访问展示层)。如果没有隔离层，就没有任何架构来限定展示层访问普通做事，难以进行权限管理。
在这个例子中，新的做事层是处于业务层之下的，展示层不能直接访问这个做事层中的组件。但是现在业务层还要通过做事层才能访问到持久层，这一点也不合理。这是分层架构中的老问题了，办理的办法是开放某些层。如表1-3所示，做事层现在是开放的了。要求可以绕过这一层，直接访问这一层下面的层。既然做事层是开放的，业务层可以绕过做事层，直接访问数据持久层。这样就非常合理。
开放和封闭层的观点确定了架构层和要求流之间的关系，并且给设计师和开拓职员供应了必要的信息理解架构里各种层之间的访问限定。如果随意的开放或者封闭架构里的层，全体项目可能都是紧耦合，一团糟的。往后也难以测试，掩护和支配。
实例为了演示分层架构是如何事情的，想象一个场景，如表1-4，用户发出了一个要求要得到客户的信息。玄色的箭头是从数据库中得到用户数据的要求流，赤色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成(客户下的订单)。
用户界面只管接管要求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的要求，它就会转发这个要求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务要求须要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息，调用order dao来得到订单信息。这些模块会实行SQL语句，然后返回相应的数据给业务层。当 customer object收到数据往后，它就会聚合这些数据然后通报给 customer delegate,然后通报这些数据到customer screen 展示在用户面前。
从技能的角度来说，有很多的办法能够实现这些模块。比如说在Java平台中，customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用大略的POJP’s(Plain Old Java Objects)，或者可以用MyBatis，还可以用JDBC或者Hibernate 查询。Microsoft平台上，customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块，用ADO来实现用户和订单数据的访问模块。
软件架构设计之分层架构（三层架构）在软件体系架构设计中，分层式构造是最常见，也是最主要的一种构造。微软推举的分层式构造一样平常分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
各层的浸染：
1：数据访问层：紧张是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也便是说，是对数据库的操作，而不是数据，详细为业务逻辑层或表示层供应数据做事．
2：业务逻辑层：紧张是针对详细的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层便是对这些积木的搭建。
3：界面层：紧张表示WEB办法，也可以表示成WINFORM办法，WEB办法也可以表现成：aspx，如果逻辑层相称强大和完善，无论表现层如何定义和变动，逻辑层都能完善地供应做事。
区分方法：
1：数据访问层：紧张看数据层里面有没有包含逻辑处理，实际上它的各个函数紧张完成各个对数据文件的操作。而不必管其他操作。
2：业务逻辑层：紧张卖力对数据层的操作。也便是说把一些数据层的操作进行组合。
3：界面层：紧张对用户的要求接管，以及数据的返回，为客户端供应运用程序的访问。
总结
分层架构是一个很可靠的架构模式。它适宜大多数的运用。如果你不愿定在项目中利用什么架构，分层架构是可以先用着的。不过从架构的角度上来说，选择这个模式还要考虑很多的东西（如污池塘反模式）。后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~
