如果把各个模块比喻成U盘,下图是我认为的架构模式
如图,个人感觉业务的接口应该要Web端来定义,而具体的业务实现放在业务模块,
1、service层是业务的接口，web层是来接受用户请求的。
2、service层的方法，不仅起到解耦的作用，而且可以被web层复用。
3.controller层，或者RPC层负责接受web请求，进行url与方法的映射，权限验证，分页控制等等。。
希望对你有所帮助~~~
大部分都是这么写的。
不过Web是接受用户输入的，service的才是业务的接口。
出了这种
还有DDD，可以看一下
我有点孤弱寡闻，只听过mvc
model
view
controller
你的理解方式不太对
业务接口是在你所说的web里面调用，但不能把接口就说放在web里面，业务接口是公用的东西，它可能还被其他web调用，它是抽象的，方便解耦，但它还是业务，不能归到web里面，dao也是一样的
感觉你对接口不是很理解，它主要是解耦和反射，并不是直接归类到web
可能你想的是接口提供规范，业务需求改变不影响web代码——这是对的，但这是接口的功用，不是架构，感觉你搞得很混淆