原文链接  作者；方腾飞

软件架构有多种架构模式，其中分层架构是目前最流行，应用最广泛的架构模式。那么什么是分层架构？为什么要采用分层架构？一个系统应该分几层合适？分层架构的好处有哪些？这些问题将是这篇文章要探讨的。大家可以在阅读本文之前先思考下这些问题，然后再看看本文的观点，看完之后欢迎通过评论进行交流。

什么是分层架构？

分层架构是将软件模块按照水平切分的方式分成多个层。一个系统由多层组成，每层由多个模块组成。那么到底分几层合适？我认为根据不同的复杂度分成不同的层次，最基本的是分层架构是三层，即表现层，领域层和数据持久层。而《领域驱动设计》Eric Evans建议分四层分别是表现层，应用层、领域层和基础层，业务逻辑在领域层，基础层比持久层的范围更大，不仅可以提供持久层服务，还可以提供缓存等服务。四层中的应用层是对三层架构中领域层进行进一步拆分。但是无论怎么分层，业务逻辑永远在领域层。

三层架构：

• 表现层：负责向用户展示信息和接收用户的指令。需要负责处理展示逻辑，比如用户通过我们的系统进行信用卡还款，系统会返回三个状态未申请，处理中，处理完成。表面层需要根据这个状态给用户返回不同的页面，根据这三个不同的状态，向用户展示不同的中文说明。
• 领域层：负责表达业务逻辑，是整个系统的核心层。比如信用卡还款服务。
• 持久层：提供数据查询和存储服务，包括按照状态查询信用卡。

四层架构

• 表现层：同三层架构表现层。
• 应用层：定义软件要完成的任务，不包含业务逻辑，而是协调，比如受理用户请求的任务。
• 领域层：同三层架构领域层。
• 基础层：为各层提供通用的技术能力。为领域层提供数据和文件存储。

以上都是是基本的分层架构，当然你可以多分几层，但是要遵循分层原则，首先是同样职责的放在一个层里，比如对外远程服务都放在一个接口层里。其次层之间不能循环依赖，包之间不能循环依赖。比如对外接口层依赖领域层，而不依赖表现层，package biz如果依赖core，那么code里的类就不应该依赖biz里的类。

在分层架构后，开发人员容易在边界问题上产生混乱，比如某个服务到底哪一层提供，比如是不是领域层和持久层都应该提供查询未还款信用卡服务？答案是否定的，分层架构最重要的是每一层关注自己的职责，持久层只负责提供查询、更新和存储数据的服务，和业务逻辑无关的，所以持久层提供按照还款状态查询信用卡的服务，这样做的好处增加复用性，后续领域层提供展示已还款的信用卡服务时能复用持久层的查询服务。

系统工程结构

掌握了分层架构之后，我们如何根据分层架构进行软件开发呢？以下是我们团队的分层开发规范，大家可以参考下

这个分层比刚才说的分层架构还多出两层，这两层做的事情如下：

• 对外接口层：所有对外的接口放在这一层里，不能包含任何业务逻辑，只数据对象的转换和异常的封装。
• 接入层：所有外部系统的依赖放在这一层，好处是一旦外部系统接口修改，我们只需要在一处修改完成。

分层架构的好处

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

• 单一职责：每一层只负责一个职责，职责边界清晰，如持久层只负责数据查询和存储，领域层只负责处理业务逻辑。
• 高内聚：分层是把相同的职责放在同一个层中，所有业务逻辑内聚在领域层。这样做有什么好处呢？试想一下假如业务逻辑分散在每一层，修改功能需要去各层修改，测试业务逻辑需要测试所有层的代码，这样增加了整个软件的复杂度和测试难度。
• 低耦合：依赖关系非常简单，上层只能依赖于下层，没有循环依赖。
• 可复用：某项能力可以复用给多个业务流程。比如持久层提供按照还款状态查询信用卡的服务，既可以给申请信用卡做判断使用，也可以给展示未还款信用卡使用。
• 易维护：面对变更容易修改。把所有对外接口都放在对外接口层，一旦外部依赖的接口被修改，只需要改这个层的代码即可。

以上这些既是分层的好处也是分层的原则，大家在分层时需要遵循以上原则，不恰当的分层会违背了分层架构的初衷。

分层架构的缺点

分层架构也有几个缺点

• 开发成本高：因为多层分别承担各自的职责，增加功能需要在多个层增加代码，这样难免会增加开发成本。但是合理的能力抽象可以提高了复用性，又能降低开发成本。
• 性能略低：业务流需要经过多层代码的处理，性能会有所消耗。
• 可扩展性低：因为上下层之间存在耦合度，所有有些功能变化可能涉及到多层的修改。

小结

本文探讨了分层架构的几个问题，根据复杂度不同系统架构可以分成三层或四层，并给出了一个系统工程结构给大家做参考，最后说明了分层架构的好处和缺点，好处是高内聚低耦合、单一职责、提高可复用性和降低维护成本。缺点是开发成本高、性能低和可扩展性低。大家在架构选型的时候，可以综合比较下分层架构的优缺点。

参考资料

• 《软件架构模式》
• 《领域驱动设计》
• 《企业应用架构模式》