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