Golang命令模式实现请求解耦方案

本文深入探讨了如何在Go语言中通过接口抽象而非继承或框架来真正落地命令模式，核心在于将请求封装（参数、上下文）与执行逻辑（Execute方法）彻底分离：handler仅依赖统一的Command接口，不导入任何具体业务模块；命令实例在启动时构造并注入，持有最小必要抽象依赖（如repository interface）；校验、日志、追踪等横切关注点交由统一的CommandRunner处理，确保业务命令专注“做什么”而非“怎么做”；同时强调命令应无状态、按完整业务动作建模、支持context传递，并严格避免全局变量、硬编码依赖及runner中的类型判断——最终实现高内聚、低耦合、易测试、可替换的请求-执行解耦架构。

命令模式在 Go 中的本质是接口抽象，不是继承或框架

Go 没有类和继承，所谓“命令模式”落地就是定义一个统一的 Command 接口，让各类业务操作都实现它。关键不在“模式名字”，而在是否真把请求封装（如参数、上下文）和执行逻辑（Execute()）拆开了。

常见错误是把 Execute() 写成直接调用 service 层函数，导致 handler 仍需 import 具体业务模块，耦合没解开。

• 真正解耦：handler 只依赖 Command 接口，不 import 任何业务文件
• 命令实例应在应用启动时构造并注入，而非在 handler 里 new 出来（否则又引入具体类型依赖）
• 命令对象应持有最小必要依赖（如 *sql.DB 或 repository interface），避免传入整个 service

如何设计可测试、可替换的 Command 接口

接口粒度决定解耦深度。太粗（如一个 Run()）难复用；太细（每个字段一个方法）增加维护成本。推荐按“一次完整业务动作”建模，例如：

type CreateUserCommand struct {
    Name     string
    Email    string
    Repo     UserRepository // 依赖抽象，非具体实现
}

func (c *CreateUserCommand) Execute(ctx context.Context) error {
    if c.Name == "" {
        return errors.New("name required")
    }
    return c.Repo.Create(ctx, User{Name: c.Name, Email: c.Email})
}

注意点：

• Execute() 接收 context.Context，便于超时、取消、trace 注入
• 所有外部依赖（DB、HTTP client、cache）必须通过字段注入，禁止全局变量或 init 时硬编码
• 不要在命令里做日志埋点或 metrics 上报——这些属于横切关注点，应由 command runner 统一包装

使用 command runner 统一处理前置/后置逻辑

真正实现“请求与执行分离”的关键环节，是把校验、日志、重试、事务等逻辑从命令内部剥离，交给 runner 管理：

type CommandRunner struct {
    logger *zap.Logger
}

func (r *CommandRunner) Execute(ctx context.Context, cmd Command) error {
    r.logger.Info("command start", zap.String("cmd", fmt.Sprintf("%T", cmd)))
    defer r.logger.Info("command end", zap.String("cmd", fmt.Sprintf("%T", cmd)))

    if err := cmd.Validate(); err != nil {
        return err
    }

    return cmd.Execute(ctx)
}

这样，业务命令只需专注“做什么”，runner 负责“怎么做、何时做、出错怎么办”。典型陷阱：

• 在 runner 里对不同命令类型做 switch 判断——说明命令接口职责不单一，应回归接口抽象
• runner 直接调用 tx.Commit() ——事务应由命令自己控制（如接收 sql.Tx 参数），runner 不该感知 DB 细节
• 把 validation 逻辑写进 runner 的通用校验函数——会导致校验规则无法随命令演进，应让每个命令实现自己的 Validate()

HTTP handler 如何零耦合调用命令

handler 唯一需要做的，是解析请求、构造命令实例、交给 runner。它不应知道命令内部怎么执行，也不该 import 任何 domain/service 包：

func CreateUserHandler(runner *CommandRunner, repo UserRepository) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        var req struct {
            Name  string `json:"name"`
            Email string `json:"email"`
        }
        if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
            http.Error(w, "bad request", http.StatusBadRequest)
            return
        }

        cmd := &CreateUserCommand{
            Name:  req.Name,
            Email: req.Email,
            Repo:  repo, // 依赖注入，但 handler 不 import repo 实现
        }

        if err := runner.Execute(r.Context(), cmd); err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        w.WriteHeader(http.StatusCreated)
    }
}

重点在于：CreateUserCommand 类型定义和 UserRepository 接口必须放在 shared 或 domain 包中，handler 和 repo 实现各自 import 这个包，彼此不直连。

最容易被忽略的是命令生命周期管理——命令对象应是无状态的（stateless），每次请求新建；若误将数据库连接池、缓存 client 等长生命周期资源塞进命令字段，会导致并发问题或资源泄漏。

理论要掌握，实操不能落！以上关于《Golang命令模式实现请求解耦方案》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！