多源同类型数据合并及多过滤规则适配的设计模式选型咨询

核心选用模式组合 #

• 策略模式（Strategy Pattern）：用来处理不同产品的查询逻辑、过滤规则的差异化问题，将Product A、Product B的完整处理逻辑封装为独立的策略实现，和上层调度逻辑完全解耦。
• 享元模式（Flyweight Pattern）：用来解决M和N次数据库调用存在重复的问题，复用相同查询的结果，避免重复访问数据库。
• 可选补充：如果所有产品的处理流程固定为「查询执行→结果合并→规则过滤」，可以搭配模板方法模式，把固定流程抽象到父类，子类只需要实现查询列表、过滤规则两个差异点即可。

1. 统一查询缓存层 #

把所有需要用到的数据库查询封装为独立的查询单元，每个查询单元对应唯一ID（可以用查询SQL+入参的哈希值生成），新增全局缓存管理：

• 执行查询前先判断缓存中是否已有该ID的查询结果，命中直接返回
• 未命中则执行数据库查询，结果写入缓存后再返回
  所有产品的查询都走这一层，重复的查询只会实际执行一次。

2. 产品策略封装 #

抽象统一的产品处理策略接口，示例逻辑如下：

// 可根据实际技术栈调整实现
interface ProductCampaignStrategy {
  // 返回当前产品需要执行的所有查询ID列表
  List<String> getRequiredQueryIds();
  // 对合并后的Campaign列表执行当前产品的过滤规则
  List<Campaign> applyFilters(List<Campaign> mergedList);
}

分别实现两个产品的策略：

• ProductAStrategy：getRequiredQueryIds返回M次查询对应的ID集合，applyFilters实现X Filters规则集
• ProductBStrategy：getRequiredQueryIds返回N次查询对应的ID集合，applyFilters实现Y Filters规则集

如果过滤规则比较复杂，包含多个可复用的子规则，可以把每个子规则封装为独立的Filter类，用责任链模式组装，不同产品的规则集只需要组合不同的Filter责任链即可，进一步降低规则的耦合度。

3. 统一调度入口 #

实现对外的统一服务类，接收客户端传入的产品类型参数：

1. 根据产品类型获取对应的策略实例
2. 调用策略的getRequiredQueryIds拿到需要执行的查询ID列表
3. 走统一查询缓存层拿到所有查询的结果，合并为单个Campaign列表
4. 调用策略的applyFilters对合并后的列表做过滤
5. 返回最终的过滤结果

该方案可以彻底解决数据库重复调用的问题，新增产品只需要新增对应的策略实现即可，不需要修改原有逻辑，完全符合开闭原则，各模块的职责单一，维护成本很低。

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