yuanxiaosong

@chaleaochexist
问题 1：在保证一个 dao 对应一个表（仅限增删改）的前提下，这个确实有很大的争论点，没有一个固定的答案，它可以叫 UserDept ，也可以 DeptUser ，但是在我看来，理论上只有一个存在，除非你底层用双向链表来维护（有两个数据库表），你用 User 打头，那么你潜意识就认为这个关联关系应该由 UserManager 来维护，反之亦然。
继续问题 1：首先确定，Service 只和 Manager 打交道，类似于事件驱动，Service 会通知每一个 Manager ，我现在要删除一个部门了，真正的执行人是 Manager ，如果关联关系是 DeptManager 维护，那么它会删除 dept 表和 dept_user ，UserManager 说关联关系不是我维护的，我直接 return ，不做任何操作，反之亦然，删除这个工作并不是 service 来完成，真正的删除是在 UserManager 和 DeptManager 中，为什么只调用某个 manager 是我们很明确其他 manager 没有和部门发生关系而已。
继续问题 1：我们目前使用一个原则来确认代码在那一层：是否抛出业务异常和 Manager 中一个方法只能对应一个动作（增/删/改）

问题 2：来个简单粗暴的，直接调用 dao 的都在 manager 中，功能权限校验/参数校验/返回结果裁剪都在 controller 中，其他的都扔在 service 中就可以了，不要过多纠结，这个没有统一标准，写的多了自然就有经验了。

@chaleaochexist 比较有争议的是这种情况，UserDao/DeptDao/UserDeptDao ，UserDao 和 UserDeptDao 肯定是直接被 UserManager 引用，现在有个需求，在部门下有人的情况下，可以直接删除部门，删除部门后，需要将部门下的人员与部门关系解除，很多人就会这样写：
class DeptManager{
void deleteDept(id){
deptDao.deleteById(id);
userDeptDao.deleteByDeptId(id);
}
}
实际上我们做法是这种；
class DeptService{
void deleteDept(id){
deptManager.deleteById(id);
userManger.deleteUserDeptByDeptId(id);
}
}
由上层去协调，如果还有业务逻辑掺杂在里面，我们还有更上层的应用层去协调：
class DeptApplication {
void deleteDept(id){
deptService.deleteById(id);
userService.deleteUserDeptByDeptId(id);
}
}

@chaleaochexist 理论上一个 dao 不会被两个 manager 调用，这个就要从上层设计来说了，领域驱动设计(DDD)应该有了解吧，我们完整的领域对象应该包括了（属性+业务方法），大概是长这个样子：
class User {
Long id;
String name;

void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
后来我们觉得应该职责分离，属性和方法分开，就变成了下面这种：
class User{
Long id;
String name;
}
class UserService extends User {
void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
再后来我们觉得方法还可以继续拆，分为业务方法和非业务方法：
class UserManager extends User {
void saveUser(){
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
class UserService extends UserManager {
void saveUser(){
// so something
userManager.saveUser();
}
}
看出来没有，我们所有的操作其实都围绕着 User 这个模型在工作，如果你有 UserAManager 和 UserBManager ，这两个都调用 UserDao 可以，但是你一个 DeptManager 调用 UserDao ，那就要考虑一下是不是你的模型设计有问题了？

@chaleaochexist 理论上一个 dao 不会被两个 manager 调用，这个就要从上层设计来说了，领域驱动设计(DDD)应该有了解吧，我们完整的领域对象应该包括了（属性+业务方法），大概是长这个样子：
class User {

}

@chaleaochexist 举个例子，现在我要做一个员工管理功能，员工信息是一个大表单，用户基本信息：姓名，账号……，用户其他信息：任职部门（多个），岗位（多个），紧急联系人（多个），工作经历（多个）……，因为要支持任意关联属性实时搜索，所以一般都是 1 个主表+n 个关联表，大概有 UserDao/UserDeptDao/UserPositionDao/UserContactDao/UserEmployHistoryDao ，每次保存/修改都要调用这么多 dao ，还有就是如果是更新，还需要更新缓存，更新 es ，那么我有一个 UserManager.saveUser(UserDTO user)，这个方法再调用 5 个 dao ，修改缓存/es ，上层的 service 方法就简单了，userManager.saveUser(user)即可，service 能够专注于处理业务逻辑，不关心数据存储，manager 关心数据存储，不关心业务逻辑，如果业务小体现不出来，像我们最多的一个主表对了 20 多个关联表，es ，redis ，es 都有，拆分了效果就很明显了。

@chaleaochexist 我这个 id 专门用来注册互联网用的，没有任何地方留有邮箱的。

针对你这种情况，我们一般是这样写：listOrders(OrderQuery query, QueryType queryType)，queryType 有两个值，实时查询/非实时查询，分别对应数据库/es ，manager 内部又有两个 私有 方法：listOrdersByDB ，listOrdersByES ，根据用户传入的 queryType 转调两个方法，这样就把业务屏蔽掉了，像你这种在方法命名上带业务，如果后期再来 N 角色，是不是要写 N 个方法？

@chaleaochexist
mq 和 controller 平级，我们认为接收 mq 也是一种外部调用方式，可能开始我们写一个 controller 来接收请求，后来解耦了，直接在 mq 中新增一个接收消息就行了，service 不用做任何变更，甚至可以支持一部分请求调用 controller ，另一部分请求发送 mq 消息。

dao 和 client 是平级，和你理解的差不多，可以简单理解 client 就是一个通过 http 通信的 db 数据库，调用接口获取一条数据和从数据库获取一条数据从上层来看没有区别；

manager 只要是用来屏蔽数据存储层的实现的，可能我们数据来源有 db/redis/es/client ，比如我获取用户，manager 中先从 redis 中获取，如果 redis 中没有，再从 mysql 中获取，然后再存储到 redis ，最后再返回给 service ；再举个例子，我们一般是一个主表和 n 个关联表，每个表对应一个 dao ，我们比较大的业务对象要产生几十个关联表，会在 manager 中合并成一个 save 方法。service 能够专注于业务逻辑处理。