本文节选自 Software Architecture Patterns
概念
最常用的架构设计模式就是分层架构，也叫层次架构，在分层架构中，具有相似功能的组件被组织在同一层，不同的层次负责不同的角色。虽然在这种架构模式中没有明确规定有多少层，一般来说分层架构都包含：presentation、business、persistence、database。在有些场景，persistence 和 database 有时候会合并成一层。
在分层架构中，每个层次在负责扮演自己的角色的同时，还需要提供一层抽象来满足来自其他层的请求，比如 presentation 在负责展示数据的同时，不需要知道数据取自于哪里，数据的提取、聚合工作是有他的下一层 business 抽象提供的。显然易见，这种分层的一个优势就是，功能分明，职责清晰。
分层架构中的数据流动
在分层架构中，数据的流向是有严格规定的，默认的情况下，数据必须经过指定的层才能到达另一个层，也就是不能跨层流动，图中 closed 标志就是在表达这样的含义。为什么数据不能跨层流动，即使某些场景下数据跨层流动显然有更好的性能，很重要的一个原因就是为了保持层的隔离性。层隔离可以让每层的变动都只影响和他直接交互的层次，而其他层则不需要做出变更，以此达到高内聚，低耦合的架构目的。
例外情况
生活总是有例外的情况，同样架构也是如此，虽然层的隔离性能够限制层次变化影响的范围，但是有些时候又需要取消这种隔离。
比如图中需要为 business 层提供具有通用功能的 service layer 来提供类似数据转换，日志等不带业务逻辑的工具功能，这个层次在架构中位于 business 层之下，也就是他是为 business 层服务的，presentation 不能直接访问他，但是按照上文 closed 的原则，意味着所有来自于 business 的请求必须要先经过 service 层才能到达 persistence，但是作为一个提供通用工具功能的层次，如果强制让所有来自 business 的请求都经过他显得多次一举，没有意义，因为并不是所有的数据都必须要进行转换或者需要日志功能，因而在这个场景之下，service 变成 open，即可以让来自 business 的请求跨过 service 访问 persistence。
层次的 open and close 是为定义层次之间的关系服务的，也决定了层次之间的数据流向，因而如果使用层次架构，架构师的职责之一就是权衡每个层次的开放性。
警惕
分层架构如此简单通用，以至于在没有找到合适的架构的时候总是可以考虑分层架构。但是这里需要值得警惕的是无意义的分层。无意义的分层就是说层次非常单薄，层次中的业务逻辑非常少或者几乎没有，导致数据的流动仅仅是为了层次的划分而必须要经过这些无意义的层。如何决定一个层是必须的？二八原则，也就是 80% 的 request 决定了这个层次存在的必要性和开闭原则，如果 80% 的request 都是简单的经过，这个层次可以考虑开放或者取消。
分层架构的度量
agility
敏捷性意味着能轻松应对变化，但是分层架构显然在这方面做的做的不够 ，如果你只是在一个层次中做出改变，可能还稍微好点，但是如果变化发生在多个层次，所耗费的精力和时间都非常多，因为分层架构一般都是单体应用，单体应用的一个显著问题就是应对变化显得耦合过重。
deployment
对一个层次中的组件进行变更通常都意味着整个层次或者整个应用必须要重新部署。
testability
每个层次的依赖都是可预测的，也就是数据流进的层次和数据流出的层次，这也意味着可以很容易实现各个层次的 mock。
performance
如果是单体应用中的分层架构，整体性能不会太低，考虑到每个数据请求都要经过多个层次，极端情况下对于那些不需要经过多个层次的数据可能会显得性能低下
scalability
由于层次的限制，如果单纯的伸缩整个应用，可能会导致某些层次有性能问题，比如单体应用横向扩展可能会导致 database 的 connection 暴涨，从而引起 db 的性能问题，此时可以考虑把 database 层单独伸缩，但是层次之间的数据交互又成了问题。
development
由于分层架构简单易实施，开发入门容易
