没太明白你说的逻辑调用是什么模式。。。。按照我的理解其实没什么不可以，但相比较之下按照模块对应要比按照逻辑对应清楚的多。
1.开发：一般开发时候分工都是按照模块分工的，举个简单的例子：比如A负责产品模块，B负责订单模块，C负责支付模块，D负责用户模块……如果你是说的按照逻辑，我理解是让A做所有的查询，B做所有的修改，C做多有的增加，D做所有的删除？因为项目已开始各自回创建个字的文件Dao和Service？这样比如修改的会用到查询，这个模块是两个人同时做的，那么并行任务就会变成串行任务，或者会出现大量重复代码。
2.部署：如果是分模块开发，每个模块的功能都是完整的，可以分布式部署成RPC模式，我只要通过远程调用就好了，哪一个模块处理问题，那个服务除了问题，我可以很快的更换哪一个模块，能最少的影响其他模块，比如订单服务坏掉了，用户还可以登陆，修改自己的信息等等。如果按照逻辑当然你也可以分布式不是，但是一台服务有问题了，比如说复杂查询的服务坏掉了，那么你连登陆都登陆不了。
3.维护：如果后期升级，加入要改成单点登录的模式，按照逻辑几乎所有文件都要更新。但是按照模块的的方式能最少的减少更新。对系统的影响是最小的。

其实我不太确定你说的逻辑调用是什么模式，一般也不一定非要对应，但基本都是按照一个模块来的。

规则是定的 但是工作中你会发现 有些不一定非要一一对应 灵活运用就好了

对应不对应都可以。
对应：即，一个service配一个dao，高内聚，体现了一个类即一个服务的思想，虽然夸了层，放在不同的类，但是从上到下浑然一体，与其他dao没有任何交集，是现在新产生的一种思想，缺点是代码量会大一点。
不对应：即，一个service可以配若干个dao，这是基于传统三层的架构演化而来，dao层的代码复用性高，说白了还是三层思想，不体现高内聚的原则，但是代码量会小很多，利于维护。