前言

要写出可维护性高的代码有很多方法论，理解分层架构思想的精髓是写好可维护性高的代码的方法之一。分层架构的思想其实就是单一职责思想的延伸，各个层次的逻辑代表不同层次的抽象，且各个层次的抽象各司其职，不同层次的逻辑从上往下单向依赖，最终构建出完整的软件系统。最常用的分层架构是三层架构，也就是界面层、业务逻辑层、数据访问层。现在比较流行的架构是DDD架构，跟三层架构相比，多了一个领域层。每个层还可以继续细分出更多更小的抽象层次，java项目的每个包路径就是代表着每个层级的抽象。我相信很多人都比较熟悉分层架构的思想，但是往往在写代码的过程中逐渐偏离了其初衷。在此，我想讲一下我们实际开发过程中需要主要的问题，通过避免一些问题去写好可维护性高的代码。

相同抽象层不要互相依赖

同级别的抽象层，不要互相依赖，可以出现单向依赖，他们之间最好保持独立，没有依赖关系最好。当同层之间出现依赖的时候，要注意一下，业务对象之间的职责是否清晰。比如出现service1的s1m1方法依赖service2的s2m1方法，service2的s2m1依赖service1的s1m2方法的情况，service1与service2就有着互相依赖的关系。这说明service1和service2关系很密切，可以考虑把service1和service2合并成同一个service，或者考虑把service2的s2m1方法移到service1，也可以考虑把service2的s2m1方法或者service1的s1m2方法单独抽到一个独立的service中去，这样就解决了同层业务对象互相依赖的问题。同理，factory、dao等其他抽象层也一样，避免设计出互相依赖的对象关系。

不同抽象层只能由上而下方向依赖

比如service层作为上层，他可以依赖dao层，而dao层作为下层，他不能向上反向依赖service层。而dao层可以往下依赖mybatis-plus底层接口，mybatis-plus可以往下依赖mybaits，mybatis可以往下依赖JDBC。

不同抽象层之间的边界要清晰

在开发过程中很容易出现不同抽象层的代码互相侵入的情况，比如：
1）直接在service层继承mybatis-plus的IService接口，或者在service层调用mybatis-plus的IService接口，这都算是dao层的实现逻辑入侵到了service层；
2）在dao层的实现做了service层该做的逻辑，而不是单纯的数据库操作，这是service层的逻辑入侵到dao层了。
3）service层DTO直接传到dao层，作为dao层的入参，或者dao层的返回参数直接使用service层返回给controller层的DTO，这都算是service层代码入侵到了dao层。dao层要定义自己的参数模型，service调用dao层时需要做参数转换。

总结

既然我们对分层架构都那么熟悉，我们在开发过程就要时刻注意，不要使自己的代码随着项目的复杂度增加而变质。