如何为现有业务模块新增认证授权并规避循环依赖

场景描述 #

系统已完成基础领域模块的独立拆分，各模块职责边界清晰，分别负责：

• 用户核心信息管理
• 用户组信息管理
• 角色配置管理
• 用户-组/角色的成员关系关联
• OAuth客户端基础配置管理
  当前需要在现有架构中新增统一的认证授权能力，但该能力天然需要对接上述所有模块的接口与数据，传统嵌入方式极易触发模块间双向引用的循环依赖问题，需要设计低耦合的结构方案。

可落地的结构设计方法 #

1. 用依赖倒置从根源切断硬依赖 #

不要让认证授权模块直接import、依赖各个基础模块的实现类，反过来由认证模块自定义所有它需要用到的抽象接口，再由各个基础模块去实现这些接口。
举个实际的实现逻辑：

• 认证模块需要校验用户状态时，在自身内部定义UserStatusCheckPort抽象，包含isUserActive(userId)方法，全程不依赖任何用户模块的类
• 具体的状态校验逻辑写在用户模块内部，由用户模块实现UserStatusCheckPort接口
• 认证模块在运行时通过依赖注入拿到接口的实现实例，不需要感知用户模块的具体存在
  这种模式下所有依赖方向永远指向抽象定义方，完全不会出现双向引用，是规避循环依赖最彻底的方式。

2. 单独拆分层级承接跨模块编排逻辑 #

不要把认证授权的跨领域逻辑硬塞进某一个现有基础模块的内部，而是单独新建一个独立的应用编排模块，这个模块是架构中唯一允许直接依赖所有基础领域模块的层级。
边界规则清晰划分：

• 所有基础模块（用户、组、角色等）只负责自身领域内的核心CRUD、业务规则校验，不处理跨领域的判断逻辑——比如用户模块只管用户的增删改查，不管“该用户能否调用某个OAuth接口”这类跨域判断
• 所有需要跨多个模块协作的认证流程（比如登录校验、权限匹配、OAuth令牌生成），全部放到这个独立的编排模块中
  因为基础模块永远不会反向调用这个编排模块的能力，所以这个模块单向依赖所有基础模块的关系是完全合法的，不会形成依赖环。

3. 用事件总线解耦隐式强依赖 #

如果希望进一步降低耦合，可以取消认证模块对各个基础模块服务接口的直接调用，改为通过全局事件总线同步数据：

• 各个基础模块在自身核心数据发生变更时（比如用户被禁用、角色权限调整、OAuth客户端密钥更新），主动向外发布对应的变更事件
• 认证模块只需要订阅这些事件，在自身内部维护一份认证所需的最小数据索引（比如用户ID、关联角色ID、OAuth客户端有效期的映射关系）
  这种模式下认证模块甚至不需要对接各个基础模块的业务接口，仅需和统一的事件总线交互，耦合度可以降到最低，也完全不存在循环依赖的可能。

4. 配套编译期规则防止依赖腐化 #

在开发流程中加入硬校验规则，避免后续迭代中逐渐形成循环依赖：

• 用规则校验工具在构建阶段做拦截，禁止所有基础领域模块反向依赖认证编排模块，一旦出现违规直接阻断构建流程
• 跨模块调用时只传递基础类型的ID值，不传递跨模块聚合的实体对象，避免因为实体类引用引发的隐式循环依赖
• 严格禁止跨模块直接操作对方的数据库表，所有数据交互必须走对方模块暴露的公开服务接口

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