有人喜欢谈论各种底层或者炫技的东西，我个人更倾向于先做好工程结构和代码规范。绝大部分情况下，我们是达不到语言或者系统的性能瓶颈的(大厂的系统除外)，多数情况下，系统慢的原因就是一个，代码写的烂！

阿里巴巴推出的《阿里巴巴java开发手册》，很具有指导意义，大部分情况下，按照规范就可以很大程度上提高代码的可读性和规范性。但是，当遇到复杂业务的项目的时候，还是稍显不足，需要再细化一下。

在Java的项目中，无论是基于maven 还是gradle做的依赖管理，工程结构都是相似的。结合《阿里巴巴java开发手册》基本还是分为controller,service,manager,dao 相对于以前的三层结构，多了一个manager层，文档上说的是作为业务下沉，以及第三方调用。这么一来，manager层就变成了整个项目中最重的一层。我们主要也是对manager的细化。

1.出于对项目发展的不确定性，我们抛弃了以往的，独立模块的做法，而是把一个项目分成只是两个模块，比如一个rest module和一个core module，这是因为随着项目的发展（特别是微服务项目中），我们原本的通信方式很可能会变化，比如从原来的restful变成了rpc。所以，我们分成两个模块，如果需要做通信方式的改变，直接重新写一个入口模块就行了。

2.由于业务的复杂度不同，原本一个manager层可以解决的问题，也许需要扩展一下才能解决。作为业务下沉层，我的理解是，如果，业务跨了单元模块，比如，文章模块在发布之后，需要发送一个通知，这种就在service中处理。但是，文章发布的时候，同时需要保存文章和文章标签和文章关系，这块业务的处理就下沉到manager层做。正常情况下，文章和关系是在两张表中，这个时候，就需要加事务来处理了。一般情况下，直接在manager中处理就行，但是，如果是在做修改的时候，我们可能还需要查询已经存在的数据，从性能考虑，我们不应该把查询操作放在事务中，这个时候，我们需要把事务操作独立出来。由于，spring的aop默认是基于jdk的动态代理，但是在类代理而不是借接口代理的时候会转换成cglib的代理，所以在同一个类中的事务调用是不生效的，所以，事务的部分也应该是独立的一个类。另外，还有多个manager中抽象出来的公共方法，这也是需要独立出来的。

另外，还有一个第三方调用的问题。一般情况下，如果是调用第三方的接口，返回对象是我们自己写的，直接调用就行了。如果对方提供了SDK，返回对象是调研方设定好的，我们还需要做一个client 本地化的操作，否则返回值在变化的时候，我们可能需要修改很多地方。

总之，我们做这些的目的，就是为了层级清晰，业务清晰，杜绝循环调用。

一图胜千言：

调用图

工程结构