如何在其他模块服务层调用外部模块DAO获取数据？

这种直接注入UserDaoImpl跨模块调用的方式确实不规范，核心问题有几点：

• 违反依赖倒置原则：直接绑定具体实现类而非接口，后续若替换UserDao的实现（比如换用MyBatis替代原生JDBC实现），所有依赖UserDaoImpl的代码都要同步修改，维护成本极高。
• 模块职责边界混乱：DAO属于模块内部的底层数据访问细节，不应该暴露给外部模块调用，会导致模块间耦合过重，后续拆分、重构都会受影响。
• 缺失业务逻辑封装：跳过业务层直接操作DAO，无法统一处理用户相关的通用逻辑（比如缓存控制、权限校验、事务管理），容易造成逻辑分散、重复代码的问题。

标准跨模块调用方案 #

1. 基于业务服务层封装调用（推荐） #

在authentication模块中新增业务服务层（Service），封装DAO操作并对外提供标准化业务接口，具体步骤：

• 在authentication模块中定义UserService接口（建议放在com.company.authentication.api包下作为对外暴露的API），包含getUserById(Long userId)这类业务方法。
• 实现UserServiceImpl，注入UserDao接口（而非实现类），在方法内部调用userDao.read(userId)完成数据查询，同时可在此添加通用业务逻辑（比如缓存校验、参数合法性判断）。
• script模块依赖authentication模块的API包，在ScriptValidator中注入UserService接口，调用其业务方法获取用户数据。

示例代码：

authentication模块的UserService实现

@Service
public class UserServiceImpl implements UserService {
    private final UserDao userDao;

    // 推荐使用构造注入，避免字段注入的弊端
    public UserServiceImpl(UserDao userDao) {
        this.userDao = userDao;
    }

    @Override
    public UserEntity getUserById(Long userId) {
        // 可在此添加通用业务逻辑：比如判断用户是否禁用、缓存查询结果等
        return userDao.read(userId);
    }
}

script模块的ScriptValidator调用

@Component
public class ScriptValidator {
    private final UserService userService;

    public ScriptValidator(UserService userService) {
        this.userService = userService;
    }

    public void validateScript(Long userId) {
        UserEntity user = userService.getUserById(userId);
        // 执行具体的校验逻辑
    }
}

2. 严格遵循模块依赖规范 #

• authentication模块仅对外暴露API层（包含Service接口、DTO等），内部的dataaccess层（DAO实现）对其他模块完全隐藏。
• script模块仅依赖authentication的API包，不直接依赖其内部实现类或数据访问层，保证模块间依赖清晰、松耦合。

3. 临时过渡方案：依赖DAO接口而非实现 #

如果暂时无法新增Service层，至少要注入UserDao接口而非UserDaoImpl，这样能避免直接绑定具体实现，符合依赖倒置原则。但这只是临时方案，仍建议尽快补充业务层封装——DAO属于底层细节，不适合跨模块暴露。

内容的提问来源于stack exchange，提问作者raga_717