在我们日常开发中，通过会将业务代码分层三层，controller、service和dao。 随着需求的迭代，会有越来越多的service，很难避免的有些service之间要耦合， 那么随之带来的问题就是bean之间的相互依赖问题，尤其是多个bean之间相互依赖， 无法直接判断是从哪个bean开始就导致相互依赖的问题。代码混乱，各层各模块之间耦合严重， 后期迭代或者维护都会变得非常困难.
这样的问题本身就是设计上有问题，所以我不是从框架代码层面去解决，而是从设计维度触发， 从一开始就得设计好层之间的联系，不仅能解决bean相互依赖问题， 还能代码复用，减少代码量，逻辑思路也会非常清晰。
当然，你也可以直接说service间相互依赖了，就直接使用dao层的方法好了， 但是在很多场景下，这样做并不方便。
我将当时做app中道具模块的思路整理一下：
作为一款社交app，狂拽酷炫的道具是必须要有的。那么就肯定会有道具商城，供用户买卖赠送。 可以想象，后期产品运营，活动，抽奖等等，道具肯定也会出现在其中。
那购买道具和使用道具这两个流程就可以抽离出来叫manager层(名称根据个人喜好)， 也就是说不论是在抽奖service中 或者商城service中都可以去调用manager中的购买和使用服务。
同理，在service层中查询出数据，肯定需要经过一定的封装或者渲染才会给到controller层， 再传给客户端去进行展示。那么也就会有很多的地方需要做同样的转换。我同样可以抽离出 一个convert层，来对模型进行渲染。
