架构设计模式
没有进行架构设计的应用程序通常是紧耦合的，难以维护和扩展。如果不理解应用的各个组件的内部工作方式的话很难看清它的架构特征。
关于部署和维护的问题都很难回答：
- 架构的规模如何？
- 程序的性能如何？
- 程序容易修改吗？
- 程序的部署模型是怎么样的？
- 程序的响应如何？
软件架构模式可以帮助你定义程序的基本特征和行为。例如一些架构模式很自然让程序成为大规模(scalable)的程序。有些模式让程序变得灵巧敏捷(agile)。知道这些架构的特征，优点和缺点，你就可以根据你特定的业务需求和目标从容地选择一种架构模式。
作为一位架构师，你总会为自己的架构选择做解释，尤其你选择一个特别的架构模式的时候。
软件架构法则
软件架构第一定律：软件架构中的所有东西都是一种权衡(Everything in software architecture is a trade-off)
我们对软件架构的定义超越了结构的范畴，包含了原则、特性等，架构的范围比单纯的结构更广，体现在我们的软件架构第二定律中：为什么比怎么做更重要（Why is more important than how）
分层架构 (Layered Architecture)
它是最通用的架构，也被叫做N层架构模式(n-tier architecture pattern)。这也是Java EE应用经常采用的标准模式。基本上是个程序员都比较熟悉它。
这种架构模式非常适合传统的IT通信和组织结构，很自然地成为大部分应用的第一架构选择。
模式描述
在分层架构中的组件被划分成几个层，每个层代表应用的一个功能，都有自己特定的角色和职能。
分层架构本身没有规定要分成多少层，大部分的应用会分成表现层、业务层、持久层和数据层。
小的应用有时候会将业务层和持久层合在一起，更大规模的应用可能会划分更多的层，比如调用外部服务的层。
分层架构的一个特性就是关注分离(separation of concerns)。该层中的组件只负责本层的逻辑，组件的划分很容易让它们实现自己的角色和职责，也比较容易地开发，测试管理和维护。
关键概念
注意每一层都是封闭的，这意味着Request必须经过每一层才能到达最底下一层。
Q：为什么不允许展示层直接访问数据库层呢，这样不是更快吗？
这就是分层架构的另一个特征：层隔离(layers of isolation)。
层隔离的概念意味着你对任何一层的改变都不会影响其它层，这很好理解，同时也意味着一个层的组件并不会了解其它层的实现，或者知道很少。
比如业务层不需知道你持久层是如何具体实现的。
分层架构也很容易增加新的层。
比如你想将一些通用的服务重构成一个服务层，比如通用图片处理，远程账户审计等，可以在业务层下增加一个服务层。它不会对展示层造成影响，也不会改变持久层的代码。
上面的这个例子带来一个问题，因为每一层丢失封闭的，业务层不得不通过服务层访问持久层，这没有天理啊。所以有时候你会创建一个开放的层。这意味着上一层可以绕过这一层直接访问下一层。
架构考量
分层架构是一个可靠的通用的架构，对很多应用来说，如果你不确定哪种架构适合你的应用，可以用它作为一个初始架构。 1、要注意的是污水池反模式(architecture sinkhole anti-pattern)
所谓污水池反模式，就是请求流简单的穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。比如一些JavaEE例子，业务逻辑层只是简单的调用了持久层的接口，本身没有什么业务逻辑。
每一层或多或少都有可能遇到这样的场景，关键是分析这样的请求的百分比是多少。二八原则可以帮助你决定是否正在遇到污水池反模式。如果你的请求超过20%，你应该考虑让一些层变成开放的。
2、需要考虑的是分层架构可能会让你的应用变得庞大
即使你的展示层和业务层可以独立发布（比如展示层使用单页技术框架AngularJS, EmberJS）。
它的确会带来一些潜在的问题，比如分布模式复杂，健壮性下降，可靠性，性能和规模等。
总结
结合上文分析，分层架构设计模式整体分析如下：
- 总体灵活性：低
- 发布易用性：低
- 可测试性：高
- 性能：低
- 规模扩展性：低
- 开发容易度：高
- END -
