分层架构

最近在项目设计时采用了领域驱动设计，在观摩《领域驱动设计》这本书时提到了layered architecture这个单词，也就是分层体系架构，觉得自己有必要对此分层架构进行一次系统的复习，记录下来以备后用

什么是分层架构？

按照字面意思理解，即将程序分成多层的一种架构模式。那需要分成几层合适呢？Eric Evans建议分为四层，分别对应表现层，应用层，领域层以及基础设施层。而最基本的是分层架构是三层，即表现层，领域层和数据持久层。

---

三层架构

名称	用途
表现层	复杂向用户显示信息和解释用户指令，用户可以是使用界面的人，也可以时另一台计算机
领域层	负责表达业务概念，业务状态信息以及业务规则，是整个系统的核心层
数据持久层	为领域层提供持久化服务，提供数据的查询和存储

四层架构

名称	用途
表现层	与三层架构中表现层一致
应用层	定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题，应用层要尽量简单，不包含业务规则，只为下一层的领域对象协调任务，分配工作
领域层	与三层架构中领域层一致
基础设施层	为上面各层提供通用化技术，为表现层绘制屏幕组件，为应用层传递消息，为领域层持久化对象

上述分层架构可以按照需要多分几层，但是分层体系架构需要遵循每层中的任何元素都仅依赖于本层的其他元素或者其下层的元素，向上通讯必须经过间接的传递机制进行。

从书上截取的一个关于网上转账的四层架构案例：

分层架构的优劣

优

分层架构的目的是通过关注点分离来降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。

• 单一职责：每一层只负责一个职责，职责边界清晰，如持久层只负责数据查询和存储，领域层只负责处理业务逻辑。

• 高内聚：分层是把相同的职责放在同一个层中，所有业务逻辑内聚在领域层。这样做有什么好处呢？试想一下假如业务逻辑分散在每一层，修改功能需要去各层修改，测试业务逻辑需要测试所有层的代码，这样增加了整个软件的复杂度和测试难度。

• 低耦合：依赖关系非常简单，上层只能依赖于下层，没有循环依赖。

• 可复用：某项能力可以复用给多个业务流程。比如持久层提供按照还款状态查询信用卡的服务，既可以给申请信用卡做判断使用，也可以给展示未还款信用卡使用。

• 易维护：面对变更容易修改。把所有对外接口都放在对外接口层，一旦外部依赖的接口被修改，只需要改这个层的代码即可。