18.7.22
dao、service、controller、model、entity。
*：dao用于操作数据库，针对表进行增删改查最基础的操作，完全根据与数据库一一对应的Entity的要求来查询数据。dao层只是负责和数据库打交道。
*：service利用dao进行业务上的处理，主要是展现需要开放出去的接口，一个service应当只调用自己对应的dao，如果需要调用其他实体的操作，需要将其他实体的service引入来使用。
*：controller做一些service前后的数据处理，利用service完成更高的操作。作为View和Model中间层。
*：model作为MVC的M是为view服务的，传递和接收view的数据。model与数据库表的字段映射，并且也添加前端需要的字段。毕竟model是为view服务的。而为了简洁就没有重复使用entity与数据库表一一对应。
*：entity为实体类，与数据库表一一对应。一般开发使用model代替了entity。
*：domain怎么回事木有十分清楚。
我们的系统是domain属于model下面，因为model为view服务，而domain则根据各个具体的模块细分。
*：VO相当于model，是视图对象，专门用于组织view需要的属性。
参考：https://www.cnblogs.com/printN/p/6901774.html
2、最近公司做项目时，遇到问题，在保存场景时需要一起保存其五类属性至各自属性表中，需要决定在场景的service模块调用属性模块的service还是dao,经查询，最终调用service层方法解决。参考网上文档内容如下：
”按我的经验，service a不能调用b的dao层，只能调用b的service层实现业务。
因为b的service是对dao的CRUD封装，如果是单库的话service或许只是dao的代理，但如果有cache，跨库查询那显然调用dao b是不合理的，可以类比为视频系统调用用户系统，视频系统不关心用户系统的dao层实现机制，只要通过service层查询到用户信息即可。
另外你说的业务依赖确实有这样的困惑，但本身java类之间通讯就是有依赖关系的，或许如果service a业务依赖的service b业务太过于复杂时你可以再次抽象出service b的另外一个interface就ok了。
个人建议不同的模块之间还是service飞来飞起就好了，不要搞到模块A的service调用模块B的dao。简单的说就是为了遵循SOA，代码结构更清晰。长远点说以后不同模块之间拆分项目/独立成jar包也是好的。举个例子， 项目里面有两个模块：账号相关模块和消息相关模块。某个用户登录需要用到账号模块获取用户信息(AccountService.getAccountByxxx)，而且拉用户未读消息（messageService.getUnRead）。用户登录这个行为可以用一个facade包装"账号模块获取用户信息" & "拉用户未读消息"。搞一个UserBehaviorFacede就是了。其次，如果像题主这种问题， 是不是用一个facade包装一下， 而不是模块调来调去？”
参考：https://blog.csdn.net/arenn/article/details/76608564
http://www.zuidaima.com/question/2378883477212160.htm
https://www.zhihu.com/question/27139263
