【架构设计】你的应用该如何分层呢？

最近review公司的代码，发现现在整个代码层级十分混乱，一个service类的长度甚至达到了5000多行。而且各种分层模型DTO、VO乱用， 最终出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动一处就牵一发而动全身等问题。,我们在吸取了阿里巴巴的分层规范以及网上的一些经验后，重新梳理总结了属于我们项目的分层规范。,我们公司原来的分层采用的是传统的三层架构，比如在构建项目的时候，我们通常会建立三个目录：Web、Service 和 Dao，它们分别对应了表现层、逻辑层还有数据访问层。,,这样导致一个很大的问题，随着业务越来越复杂，逻辑层也就是service层越来越庞大，所以出现了前面说的5000多行的类，可想而知维护成本有多大。,参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0（详尽版）》，我们可以将原先的三层架构细化成下面的样子：,,在这个分层架构中主要增加了 Manager 层，它可以将Service层中的一些通用能力比如操作缓存、消息队列的操作下沉，也可以将通过feign调用其他服务的接口进行一层包装，再提供给Service调用，这也就是所谓的防腐层。,前面讲解了整体的一个分层架构，那么在不同的层级之间必然需要一些模型对象进行流转传递，VO，BO，DO，DTO, 那么他们之间有什么区别呢？,VO​比较容易混淆的是DTO，DTO​是展示层与服务层之间传递数据的对象，可以这样说，对于绝大部分的应用场景来说，DTO和VO​的属性值基本是一致的，而且他们通常都是POJO​，那么既然有了VO​，为什么还需要DTO呢？,例如服务层有一个getUser​的方法返回一个系统用户，其中有一个属性是gender(性别)，对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。,从用途上进行根本的区别，BO是业务对象，DTO是数据传输对象，虽然BO也可以排列组合数据，但它的功能是对内的，但在提供对外接口时，BO对象中的某些属性对象可能用不到或者不方便对外暴露，那么此时DTO只需要在BO的基础上，抽取自己需要的数据，然后对外提供。在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成。,我们项目根据实际情况总结了分层领域模型的规范：,可以参考github上面的https://github.com/alvinlkk/mall4cloud这个项目，它是一个极度遵守阿里巴巴代码规约的项目。,,这里面有个关于Feign设计的亮点, 主要是为了避免服务提供方修改了接口，而调用方没有修改导致异常的问题。,,,我们来看下整体的一个结构。,