租户分类场景下应选用哪种设计模式？（Java 11+Spring Boot）

现有业务基础 #

• 支持对Tenant的CRUD操作，业务层对应实现完整业务方法
• 可操作Tenant的角色限制：仅允许Role_A和Role_B用户操作
• 调用链路：TenantController -> TenantService -> TenantDAO

新业务场景 #

引入tenantCategory字段，区分两类租户：

• 旧租户：Tenant_A
• 新增租户：Tenant_B

当前实现问题 #

在TenantService中通过大量if-else分支处理新需求，包含以下逻辑：

• 字段处理：跳过部分字段、添加新字段
• 校验逻辑：新增专属校验规则
• 授权控制：通过if-else结合@PreAuthorization实现权限差异（原逻辑允许Role_A、Role_B操作，新租户Tenant_B仅允许Role_B操作）

设计模式选型分析 #

针对Strategy、Decorator、Visitor三种模式，适配性分析如下：

1. 策略模式（Strategy） #

适配性最高，核心原因：

• 两类租户的业务逻辑（字段处理、校验、授权）属于同一类型的不同行为变体，完全契合策略模式"封装不同算法/行为，运行时动态切换"的核心思想
• 可将Tenant_A和Tenant_B的专属逻辑分别封装为TenantAStrategy和TenantBStrategy，通过TenantStrategyFactory根据tenantCategory动态获取对应策略
• 授权逻辑可在策略类中结合Spring Security的权限判断实现，避免在Service中硬编码分支；也可在策略方法上标注对应@PreAuthorization注解，实现细粒度权限控制
• 后续新增租户类型时，只需新增策略类，无需修改原有Service代码，完全符合开闭原则

2. 装饰器模式（Decorator） #

适配性较弱：

• 装饰器模式核心是动态增强对象功能，适合在原有逻辑基础上叠加新能力，但本次需求是两类租户的逻辑存在分支差异（而非增强），用装饰器会导致逻辑拆分混乱，反而增加系统复杂度

3. 访问者模式（Visitor） #

适配性极低：

• 访问者模式适用于固定数据结构，多变操作逻辑的场景，而本次需求是租户类型变化带来的行为差异，数据结构本身存在字段差异且并非固定，不符合访问者模式的适用场景

落地建议 #

1. 定义TenantStrategy接口，声明CRUD操作的核心方法，例如validateTenant(Tenant tenant)、processTenantFields(Tenant tenant)、checkAuthorization(Authentication auth)等
2. 实现TenantAStrategy和TenantBStrategy两个具体策略类，分别实现对应租户的专属逻辑
3. 改造TenantService，注入TenantStrategyFactory，在业务方法中根据tenantCategory获取对应策略，调用策略方法完成业务逻辑
4. 授权逻辑可在策略类中通过SecurityContextHolder获取当前用户身份信息，结合租户类型判断权限；若使用@PreAuthorization，可将权限注解标注在策略类的对应方法上，确保权限控制的精准性

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