支付场景设计模式组合实现
一、核心逻辑：用Spring体系串联5种模式，实现“创建-增强-选择-流程-监控”全链路
二、分步骤落地
-
模板方法模式：定义支付标准流程
先抽象支付流程，所有支付方式必须遵循：验签→扣钱→回调通知。
用Spring @Component定义抽象类AbstractPayTemplate，包含final方法pay()固定流程，抽象方法verifySign()、deductMoney()、callback()留给子类实现。 -
策略模式：多支付方式实现
定义策略接口PayStrategy，继承AbstractPayTemplate。
支付宝实现类AlipayStrategy：重写验签（支付宝公钥验签）、扣钱（调用支付宝SDK）、回调（解析支付宝回调参数），用@Component("alipay")注册到Spring容器。
微信实现类WechatPayStrategy：同理，用@Component("wechat")注册。 -
工厂模式：根据类型获取支付策略
用Spring IoC容器做工厂，无需手动new对象。
创建PayFactory，注入Map<String, PayStrategy> payStrategyMap，Spring会自动将所有PayStrategy的Bean按@Component的value存入Map。
工厂方法getPayStrategy(String type)：根据前端传入的type，从Map中直接获取对应策略Bean。 -
装饰器模式：增强支付功能
对支付流程增加“日志记录”“限流”功能，不修改原有策略类。
创建装饰器类PayDecorator implements PayStrategy，构造方法注入PayStrategy，重写pay()方法：先执行装饰逻辑，再调用被装饰对象的pay()。
用Spring @Bean创建装饰后的策略Bean：@Bean("decoratedAlipay") public PayStrategy decoratedAlipay(@Qualifier("alipay") PayStrategy alipay) { return new PayDecorator(alipay); }，工厂模式后续可直接获取装饰后的Bean。 -
代理模式+AOP：支付监控
用Spring AOP实现无侵入监控，定义切面PayMonitorAspect，@Around(“execution(* com.xxx.pay.PayStrategy.pay(…))”)，在环绕通知中记录支付耗时、成功/失败状态，异常时记录错误日志，直接整合到Spring容器，无需修改业务代码。
三、Spring体系下的最佳组合
- 依赖注入：所有策略、工厂、装饰器、AOP切面均由Spring管理，通过@Autowired注入，避免硬编码依赖。
- 自动装配：工厂模式通过Map自动收集策略Bean，减少手动配置。
- 无侵入增强：装饰器模式增强功能，AOP代理监控，均不修改核心支付逻辑，符合“开闭原则”。
- 高并发适配：结合Spring的单例Bean+AOP限流，支撑高并发支付场景。
四、调用流程
前端传入支付类型→Controller调用PayFactory.getPayStrategy(type)→工厂从Spring容器获取装饰后的策略Bean→调用pay()方法→先执行装饰器的增强逻辑→进入模板方法的固定流程→执行具体策略的验签/扣钱/回调→AOP切面记录监控日志。
这种组合完全基于Spring体系，用最经典的模式解决多支付+增强+监控问题，无冗余代码，符合实际开发落地。
电商多来源日志记录：多设计模式组合实践
一、业务背景
电商日志来源多，需统一记录但各来源逻辑不同，同时要支持日志增强和监控，用“策略+工厂+装饰器+代理+观察者”组合，基于Spring体系落地。
二、模式组合落地
-
策略模式：定义多来源日志处理策略
抽象策略接口LogHandler，方法handle(LogDTO log)。
实现类：OrderLogHandler、PayLogHandler、UserLogHandler，分别处理订单、支付、用户日志，用@Component("orderLog")等注册到Spring。 -
工厂模式：根据日志来源获取策略
创建LogHandlerFactory，注入Map<String, LogHandler> logHandlerMap，Spring自动收集所有LogHandlerBean。
工厂方法getHandler(String source)：根据日志DTO中的source字段，从Map取对应策略，避免if-else判断来源。 -
装饰器模式：日志增强
对原始日志增加“脱敏”“补全traceId”功能，不修改策略类。
装饰器LogDecorator implements LogHandler，构造注入LogHandler，重写handle()：先脱敏手机号/身份证，补全分布式traceId，再调用被装饰策略的handle()。
Spring中用@Bean创建装饰Bean：@Bean("decoratedOrderLog") public LogHandler decoratedOrderLog(@Qualifier("orderLog") LogHandler handler) { return new LogDecorator(handler); }，工厂后续返回装饰后的策略。 -
代理模式+AOP：日志监控
定义AOP切面LogMonitorAspect，@Around(“execution(* com.xxx.log.LogHandler.handle(…))”)，记录日志处理耗时、成功/失败状态，异常时标记日志为“处理失败”，对接告警系统。 -
观察者模式：日志异步分发
日志处理后，需异步同步到ELK、数据仓库。
发布LogHandledEvent事件，ElkObserver、DataWarehouseObserver实现ApplicationListener，用@Async异步监听，执行同步逻辑，不阻塞日志主流程。
三、Spring体系下的调用流程
业务系统产生日志→通过Spring事件发布LogEvent→日志收集器接收后，调用LogHandlerFactory.getHandler(source)→获取装饰后的策略Bean→执行handle()：装饰器先增强日志→策略类处理具体来源逻辑→AOP记录监控→处理完成后发布LogHandledEvent→观察者异步同步日志到ELK/数据仓库。
四、企业价值
这种组合让日志系统“新增来源只需加策略类、新增增强只需加装饰器”，完全符合电商“高扩展、低耦合、可监控”需求，是中大型电商日志平台的标准实现。
在电商场景中，除了支付、日志，还有以下3个典型的多设计模式组合场景，均基于Spring体系落地，核心解决“高扩展、低耦合、高并发”问题：
一、商品库存管理（秒杀/普通下单通用）
模式组合：策略+工厂+代理+单例+观察者
- 策略模式：定义
StockStrategy接口，实现NormalStockStrategy、SeckillStockStrategy，分别注册为Spring Bean。 - 工厂模式：
StockFactory注入Map<String, StockStrategy>，根据商品类型获取策略，避免if-else。 - 代理模式+AOP：用AOP切面拦截库存扣减方法，实现Redis分布式锁防超卖、库存操作日志记录。
- 单例模式：Spring默认单例管理
StockStrategy，减少对象创建开销，高并发下更高效。 - 观察者模式：库存扣减成功后，发布
StockDeductedEvent，观察者异步更新商品缓存、通知订单系统，不阻塞主流程。
二、订单状态流转（创建→支付→发货→完成）
模式组合：状态模式+模板方法+代理+观察者
- 状态模式：定义
OrderState接口，实现CreatedState、PaidState、ShippedState、CompletedState，每个状态封装对应操作逻辑，订单对象持有当前状态，状态流转时只需切换状态对象，无需大量if-else判断状态。 - 模板方法模式：抽象
AbstractOrderFlow，定义订单流转固定流程，抽象方法validate()、execute()留给子类实现，保证不同订单类型流程统一。 - 代理模式+AOP：AOP拦截订单状态变更方法，记录状态变更日志、监控状态流转耗时，异常时触发告警。
- 观察者模式：订单状态变更后，发布
OrderStatusChangedEvent，观察者异步发送用户通知、更新订单统计数据。
三、商品搜索推荐（用户搜索→商品匹配→排序→推荐）
模式组合：策略+工厂+装饰器+代理
- 策略模式：定义
SearchStrategy接口，实现KeywordSearchStrategy、CategorySearchStrategy、HotSearchStrategy，分别处理关键词搜索、分类搜索、热门搜索，策略Bean注册到Spring。 - 工厂模式：
SearchFactory注入Map<String, SearchStrategy>，根据用户搜索类型获取对应策略。 - 装饰器模式：对搜索结果增加“过滤下架商品”“补全商品标签”增强逻辑，装饰器
SearchResultDecorator包装原策略，不修改搜索核心逻辑。 - 代理模式+AOP：AOP拦截搜索方法，记录搜索关键词、搜索耗时、点击率，用于后续推荐算法优化，同时实现搜索接口限流，防止恶意请求。
在金融项目中，以下3个场景是多设计模式组合的经典落地，核心围绕“事务安全、数据一致、可追溯”，且完全基于Spring体系实现：
一、资金转账流程（核心场景，强事务要求）
模式组合：模板方法+策略+代理+观察者+工厂
- 模板方法模式：抽象
AbstractTransferTemplate，定义“验户→扣账→转账→记账”固定流程，抽象方法verifyAccount()、deductFund()、transfer()、recordAccounting()留给子类实现，确保不同转账类型流程统一。 - 策略模式：定义
TransferStrategy接口继承模板类，实现IntraBankTransferStrategy、InterBankTransferStrategy，分别处理行内/跨行转账，策略Bean注册到Spring。 - 工厂模式：
TransferFactory注入Map<String, TransferStrategy>，根据转账类型获取策略，避免硬编码判断。 - 代理模式+AOP：AOP拦截转账方法，用
@Transactional保证事务原子性，同时记录转账流水、监控耗时和成功率，异常时触发风控告警。 - 观察者模式：转账成功后，发布
TransferSuccessEvent，观察者异步执行“对账文件生成”“客户短信通知”，不阻塞主流程但保证事务提交后才触发。
二、风控规则引擎（实时拦截风险交易）
模式组合：责任链+策略+工厂+代理
- 责任链模式：定义
RiskRuleHandler接口，实现AmountRuleHandler、FrequencyRuleHandler、BlacklistRuleHandler，每个处理器按顺序执行规则，通过setNext()形成链条，任一规则拦截则终止交易。 - 策略模式：不同业务线的风控规则不同，定义
RiskStrategy接口，实现PersonalLoanRiskStrategy、CreditCardRiskStrategy，每个策略封装对应责任链，策略Bean注册到Spring。 - 工厂模式：
RiskFactory注入Map<String, RiskStrategy>，根据业务线获取风控策略。 - 代理模式+AOP：AOP记录风控规则执行结果、拦截耗时，用于规则优化和风险追溯。
三、对账处理系统（日终/实时对账，数据一致）
模式组合：模板方法+策略+装饰器+观察者
- 模板方法模式：抽象
AbstractReconciliationTemplate，定义“文件下载→数据解析→对账匹配→差异处理→结果入库”固定流程，抽象方法留给子类实现，保证对账流程标准化。 - 策略模式：定义
ReconciliationStrategy接口继承模板类，实现BankReconciliationStrategy、PaymentReconciliationStrategy，分别处理银行对账、支付渠道对账，策略Bean注册到Spring。 - 装饰器模式：对原始对账数据增加“数据清洗”“格式转换”增强逻辑，装饰器
ReconciliationDataDecorator包装原策略，不修改对账核心逻辑。 - 观察者模式：对账完成后，发布
ReconciliationCompletedEvent，观察者异步处理“差异告警”“对账报表生成”，确保对账结果及时反馈。
扫一扫
349
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
