模型+服务
其实业务层应该描述的是在需求分析中得到的所有一定领域的问题，把这些域问题通过建模，分解为模型+服务。hivemind可以把每个模型或服务完全再独立起来放到目录里，通过配置可在需要时在目录中寻找调用。这也就体现了Ioc的过人之处，使得设计非常灵活有些组件化的感觉。构建系统就像搭积木，这时你可以把所有的模型和服务统称为Service，你提供的Service的多少可以决定你的系统具备哪些功能。而这些Service就相当于积木实体，而Service之间的关联相当于积木怎么摆放，这就看你自己的想象力有多丰富，积木搭建的漂亮，说明你的业务层做得比较完善。
HiveMind的Ioc和JdonFramework都是autowiring的，而Spring推荐使用是非autowiring，可能大家从非autowiring到autowiring有一个过程，很显然，在我的实践中，autowiring大大提高设计调试时间。
在设计调试时，大量类需要调整来调整去，A原来调用B，我想改成C调用B，那么只要将B接口代码转移到C中即可，autowiring将自动帮助配对，但是如果是非autowiring，那么这种调整，除了代码修改外，配置还需要，当然JDK5.0中使用元注释+配置可能会好些，但是无论如何，autowiring在搭积木时效率要高，特别是有几百个类时。
当我们可把业务层构件细分到类时，灵活性增强了，但是因为太细致，就需要autowiring帮助提高效率，否则过分注重细节也是很累人的。
是这样，都是POJO了，业务层和持久层的分层是设计，有时不能表现在代码上，Evans DDD对业务层继续分层：模型服务，我们也没有明显的代码区分标志，这是正常的，我们可以通过包名来区分。