Go 网关模式：让业务逻辑和外部服务“保持距离“的艺术

场景小剧场想象一下你的电商系统要接支付功能。如果直接在order包里写stripe.Charge()明天老板说换支付宝你就要满世界改代码 网关模式就是给业务逻辑装个万能插座不管插什么支付服务业务代码都不用动 核心三原则 高层模块订单不该依赖底层模块支付 两者都依赖抽象接口 接口由用的人定义而不是做的人这其实就是 SOLID 里的依赖倒置接口隔离原则但咱不背八股文看代码 代码三连击1️⃣ 外部服务干脏活的 Stripe 客户端// external/stripe/gateway.gotypeStripeGatewaystruct{APIKeystring}func(s*StripeGateway)Charge(amountint64,currency,sourcestring)(string,error){fmt.Printf( Stripe] 扣款 %d %s from %s\n,amount,currency,source)returntxn_live_123,nil// 假装调用成功}2️⃣ 业务逻辑只关心能扣款的接口// order/service.go ✨ 接口由使用者定义typepaymentGatewayinterface{Charge(amountint64,currency,sourcestring)(string,error)}typeServicestruct{gateway paymentGateway}func(s*Service)Checkout(amountint64,sourcestring)error{_,err:s.gateway.Charge(amount,USD,source)// 只依赖抽象returnerr}3️⃣ 单元测试Mock 一下快乐翻倍// 测试时塞个假网关不花一分钱typemockGatewaystruct{calledbool}func(m*mockGateway)Charge(...)(string,error){m.calledtrue;returntxn_mock,nil}funcTestCheckout(t*testing.T){mock:mockGateway{}order.NewService(mock).Checkout(1000,card_abc)// ✅ 验证业务逻辑不依赖真实网络}️ 架构关系图依赖接口实现实现实现订单业务 orderpaymentGatewayStripe实现支付宝实现测试Mock 这个模式香在哪优势说明易替换换支付渠道改一行注入代码就行好测试Mock 接口单元测试秒出结果低耦合业务逻辑不知道谁在扣款只知道能扣款接口精简只定义需要的Charge方法拒绝接口污染 实战小贴士// main.go 组装时刻✨stripe:stripe.NewStripeGateway(sk_live_xxx)orderSvc:order.NewService(stripe)// 依赖注入// 想换支付宝只需// alipay : alipay.New(...)// orderSvc : order.NewService(alipay)思考题如果支付网关需要ChargeRefund两个方法但你的业务只需要扣款接口该怎么设计答案还是只定义Charge接口隔离原则安排上 总结网关模式本质是控制依赖方向——让稳定的业务逻辑主导接口定义易变的外部实现去适配它。下次写代码前问问自己“是谁在依赖谁”代码如人生保持适当距离关系更长久