3. 依赖隔离原则：接口抽象、依赖反转、适配器模式在OAuth2.0中的应用

在OAuth2.0 Mock服务的构建中，依赖隔离是确保系统可测试、可移植、可演进的核心原则。当真实授权服务器（如Keycloak、Okta、Spring Authorization Server）与Mock实现之间缺乏清晰边界时，任何底层库升级、协议版本变更或环境切换都会引发连锁修改。本章通过接口抽象、依赖反转（DIP）与适配器模式，构建一套“换芯不换壳”的OAuth2.0隔离架构。

3.1 依赖隔离的三层防线

依赖隔离并非单一技巧，而是由三个层次共同构成的防御体系。下表总结了各层职责与典型实现方式：

3.2 接口抽象：定义稳定的OAuth2.0契约

接口抽象是依赖隔离的基石。在OAuth2.0 Mock中，我们需要为每个核心交互点定义抽象接口，而非直接依赖具体实现类。以下是一个典型的Token内省服务接口：

public interface TokenIntrospectionService {
    /**
     * 内省access_token，返回标准化的Token元数据。
     * @param token 待验证的access_token
     * @return TokenIntrospectionResponse 包含active、scope、client_id等字段
     */
    TokenIntrospectionResponse introspect(String token);
    
    /**
     * 批量内省（可选，用于性能优化场景）
     */
    Map<String, TokenIntrospectionResponse> introspectBatch(List<String> tokens);
}

接口抽象的关键设计原则：

• 参数与返回值标准化：使用DTO对象而非原始Map，避免协议细节泄露。
• 异常契约明确：定义 TokenInvalidException、TokenExpiredException 等业务异常，而非抛出通用 RuntimeException。
• 无框架依赖：接口层不应引入Spring、Servlet等框架注解，保持纯POJO。

3.3 依赖反转：让控制权回归业务

依赖反转原则（DIP）要求：高层模块不应依赖低层模块，二者都应依赖抽象。在OAuth2.0 Mock中，这意味着业务逻辑（如资源服务器过滤器）只依赖 TokenIntrospectionService 接口，而不关心底层是调用数据库、Redis还是远程HTTP。

Spring生态中典型的DIP实现方式：

@Configuration
public class OAuth2MockConfig {
    
    @Bean
    @ConditionalOnProperty(name = "oauth2.mock.store", havingValue = "redis")
    public TokenIntrospectionService redisTokenIntrospection(RedisTemplate<String, Object> redisTemplate) {
        return new RedisTokenIntrospectionService(redisTemplate);
    }
    
    @Bean
    @ConditionalOnProperty(name = "oauth2.mock.store", havingValue = "jdbc", matchIfMissing = true)
    public TokenIntrospectionService jdbcTokenIntrospection(DataSource dataSource) {
        return new JdbcTokenIntrospectionService(dataSource);
    }
    
    @Bean
    @ConditionalOnProperty(name = "oauth2.mock.store", havingValue = "remote")
    public TokenIntrospectionService remoteTokenIntrospection() {
        return new RemoteTokenIntrospectionService("https://auth.example.com/introspect");
    }
}

3.4 适配器模式：桥接异构系统

当我们需要将第三方OAuth2.0实现（如Keycloak、Okta SDK）集成到Mock架构中时，适配器模式成为关键工具。适配器将外部SDK的不兼容接口转换为系统内部的抽象接口，实现“插拔式”集成。

以下是将Keycloak的 TokenVerifier 适配为 TokenIntrospectionService 的典型实现：

public class KeycloakTokenIntrospectionAdapter implements TokenIntrospectionService {
    
    private final TokenVerifier<AccessToken> keycloakVerifier;
    
    public KeycloakTokenIntrospectionAdapter(String jwksUrl, String realm) {
        // 初始化Keycloak原生的TokenVerifier
        this.keycloakVerifier = TokenVerifier.create(
            AccessToken.class, 
            KeycloakTokenIntrospectionAdapter.class.getClassLoader()
        ).withDefaultUrl(jwksUrl);
    }
    
    @Override
    public TokenIntrospectionResponse introspect(String token) {
        try {
            AccessToken accessToken = keycloakVerifier.verifyToken(token);
            return TokenIntrospectionResponse.builder()
                .active(true)
                .clientId(accessToken.getIssuedFor())
                .scope(String.join(" ", accessToken.getRealmAccess().getRoles()))
                .exp(accessToken.getExpiration())
                .build();
        } catch (VerificationException e) {
            return TokenIntrospectionResponse.builder()
                .active(false)
                .build();
        }
    }
    
    @Override
    public Map<String, TokenIntrospectionResponse> introspectBatch(List<String> tokens) {
        // 批量处理逻辑，可加入缓存优化
        return tokens.stream()
            .collect(Collectors.toMap(Function.identity(), this::introspect));
    }
}

3.5 架构全景：依赖隔离在OAuth2.0 Mock中的落地

下图展示了依赖隔离原则在OAuth2.0 Mock服务中的完整架构。业务层、抽象层、适配层三层分离，各层职责清晰，变更影响范围被严格限制。

3.6 实战对比：隔离前后代码质量差异

以下表格对比了未使用依赖隔离与使用完整三层隔离后的代码质量指标，数据来自实际项目重构前后的度量：