Chain of Responsibility in Go

The Problem

It is common to start with one large validation function that checks inventory, payment rules, fraud signals, and shipping data all at once. That grows into brittle code quickly: every new rule touches the same function, testing becomes tedious, and reordering behavior is risky.

func ValidateOrder(order Order) error {
    // inventory, payment, fraud, and address logic all mixed together
    return nil
}

That is especially awkward in Go, where small functions and explicit composition are usually easier to maintain.

The Solution

Chain of Responsibility breaks the workflow into focused handlers. Each handler checks one concern and optionally forwards the request to the next handler. In Go, the chain is built with a small interface and struct composition, not inheritance.

Structure

Chain of Responsibility Pattern

Step 1 of 6

The Client

ValidationChainService wires the chain once and calls Validate. It knows only the first handler — not how many steps follow or which validators are in the chain.

flowchart LR
Client["ValidationChainService"]
H1["InventoryCheck"]
H2["PaymentValidation"]
H3["FraudDetection"]
H4["AddressValidation"]

Client -->|"Validate(order)"| H1
H1 -->|"next"| H2
H2 -->|"next"| H3
H3 -->|"next"| H4

Handler interface: OrderValidator defines SetNext, Validate, and Check.
Base handler: Shared forwarding logic lives in BaseHandler.
Concrete handlers: Inventory, payment, fraud, and address validators each own one responsibility.
Client: ValidationChainService wires the chain once and executes it.

Implementation

This example runs an order through four validation steps and collects the result from each handler so the caller can inspect the full pipeline.

package main

type ValidationResult struct {
	HandlerName string
	Valid       bool
	Errors      []string
}

type Item struct {
	Name  string
	Price float64
	Qty   int
}

type Address struct {
	Street  string
	City    string
	Zip     string
	Country string
}

type OrderData struct {
	Items           []Item
	PaymentMethod   string
	TotalAmount     float64
	ShippingAddress Address
}

type OrderValidator interface {
	SetNext(OrderValidator) OrderValidator
	Validate(order OrderData) []ValidationResult
	Check(order OrderData) ValidationResult
}

package main

type BaseHandler struct {
	next OrderValidator
}

func (h *BaseHandler) SetNext(handler OrderValidator) OrderValidator {
	h.next = handler
	return handler
}

func (h *BaseHandler) validateNext(order OrderData) []ValidationResult {
	if h.next != nil {
		return h.next.Validate(order)
	}
	return nil
}

package main

import "fmt"

type InventoryCheckHandler struct {
	BaseHandler
}

func (h *InventoryCheckHandler) Validate(order OrderData) []ValidationResult {
	result := h.Check(order)
	return append([]ValidationResult{result}, h.validateNext(order)...)
}

func (h *InventoryCheckHandler) Check(order OrderData) ValidationResult {
	errors := make([]string, 0)

	for _, item := range order.Items {
		if item.Qty <= 0 {
			errors = append(errors, fmt.Sprintf("%s has invalid quantity %d", item.Name, item.Qty))
		}
		if item.Name == "out-of-stock-item" {
			errors = append(errors, fmt.Sprintf("%s is out of stock", item.Name))
		}
	}

	return ValidationResult{
		HandlerName: "InventoryCheckHandler",
		Valid:       len(errors) == 0,
		Errors:      errors,
	}
}

package main

import "fmt"

type PaymentValidationHandler struct {
	BaseHandler
}

func (h *PaymentValidationHandler) Validate(order OrderData) []ValidationResult {
	result := h.Check(order)
	return append([]ValidationResult{result}, h.validateNext(order)...)
}

func (h *PaymentValidationHandler) Check(order OrderData) ValidationResult {
	errors := make([]string, 0)

	validMethods := []string{"credit_card", "debit_card", "paypal", "bank_transfer"}
	isValidMethod := false
	for _, method := range validMethods {
		if order.PaymentMethod == method {
			isValidMethod = true
			break
		}
	}

	if !isValidMethod {
		errors = append(errors, fmt.Sprintf("invalid payment method: %s", order.PaymentMethod))
	}

	if order.TotalAmount <= 0 {
		errors = append(errors, "total amount must be positive")
	}

	return ValidationResult{
		HandlerName: "PaymentValidationHandler",
		Valid:       len(errors) == 0,
		Errors:      errors,
	}
}

package main

import "strings"

type FraudDetectionHandler struct {
	BaseHandler
}

func (h *FraudDetectionHandler) Validate(order OrderData) []ValidationResult {
	result := h.Check(order)
	return append([]ValidationResult{result}, h.validateNext(order)...)
}

func (h *FraudDetectionHandler) Check(order OrderData) ValidationResult {
	errors := make([]string, 0)

	if order.TotalAmount > 10000 {
		errors = append(errors, "high value orders require manual review")
	}

	if strings.EqualFold(order.ShippingAddress.Country, "banned_country") {
		errors = append(errors, "shipping destination is blocked")
	}

	if len(order.Items) == 0 {
		errors = append(errors, "empty orders should be rejected before payment")
	}

	return ValidationResult{
		HandlerName: "FraudDetectionHandler",
		Valid:       len(errors) == 0,
		Errors:      errors,
	}
}

package main

import (
	"regexp"
	"strings"
)

type AddressValidationHandler struct {
	BaseHandler
}

func (h *AddressValidationHandler) Validate(order OrderData) []ValidationResult {
	result := h.Check(order)
	return append([]ValidationResult{result}, h.validateNext(order)...)
}

func (h *AddressValidationHandler) Check(order OrderData) ValidationResult {
	errors := make([]string, 0)
	addr := order.ShippingAddress

	if strings.TrimSpace(addr.Street) == "" {
		errors = append(errors, "street is required")
	}
	if strings.TrimSpace(addr.City) == "" {
		errors = append(errors, "city is required")
	}
	if strings.TrimSpace(addr.Zip) == "" {
		errors = append(errors, "zip code is required")
	}
	if strings.TrimSpace(addr.Country) == "" {
		errors = append(errors, "country is required")
	}

	zipPattern := regexp.MustCompile(`^\d{5}(-\d{4})?$`)
	if addr.Zip != "" && !zipPattern.MatchString(addr.Zip) {
		errors = append(errors, "zip code format is invalid")
	}

	return ValidationResult{
		HandlerName: "AddressValidationHandler",
		Valid:       len(errors) == 0,
		Errors:      errors,
	}
}

package main

type ValidationChainService struct {
	chain OrderValidator
}

func NewValidationChainService() *ValidationChainService {
	inventoryHandler := &InventoryCheckHandler{}
	paymentHandler := &PaymentValidationHandler{}
	fraudHandler := &FraudDetectionHandler{}
	addressHandler := &AddressValidationHandler{}

	inventoryHandler.SetNext(paymentHandler).SetNext(fraudHandler).SetNext(addressHandler)

	return &ValidationChainService{chain: inventoryHandler}
}

func (s *ValidationChainService) ValidateOrder(order OrderData) []ValidationResult {
	return s.chain.Validate(order)
}

package main

import "fmt"

func main() {
	service := NewValidationChainService()

	order := OrderData{
		Items: []Item{
			{Name: "Laptop", Price: 1000, Qty: 1},
			{Name: "Mouse", Price: 50, Qty: 2},
		},
		PaymentMethod: "credit_card",
		TotalAmount:   1100,
		ShippingAddress: Address{
			Street:  "123 Main St",
			City:    "Phnom Penh",
			Zip:     "12000",
			Country: "Cambodia",
		},
	}

	results := service.ValidateOrder(order)

	fmt.Println("=== Chain of Responsibility in Go ===")
	for _, result := range results {
		fmt.Printf("%s valid=%t\n", result.HandlerName, result.Valid)
		for _, err := range result.Errors {
			fmt.Printf("  - %s\n", err)
		}
	}
}

Real-World Analogy

Think of airport security. Your bag moves through identity check, scanning, secondary inspection, and final clearance. Each checkpoint focuses on one responsibility and passes the traveler forward only if that step succeeds.

Pros and Cons

Pros	Cons
Breaks large workflows into small, reorderable steps.	Control flow can become harder to trace across many handlers.
Makes each handler easier to test in isolation.	Long chains may hide where failures really come from.
Lets different deployments assemble different pipelines.	Can be heavier than a plain slice of functions for simple fixed pipelines.

Best Practices

Use small handlers with one reason to change.
Prefer composition. The shared chain behavior belongs in an embedded helper, not a deep type hierarchy.
Keep handler contracts explicit. Returning structured validation results is usually easier to debug than a single boolean.
Wire the chain at the edge of the system so the caller does not know which concrete validators exist.
Do not build a chain when a plain slice of functions would do. The pattern is useful when sequencing and substitution matter.

When to Use

A request must pass through several optional or reorderable steps.
Different deployments or workflows need different validation chains.
You want each step to be testable in isolation.

When NOT to Use

There is only one step, so a direct call is clearer.
The full pipeline is fixed and trivial, making a slice of plain functions simpler.
The chain becomes so long that tracing control flow is harder than a direct implementation.

Command Pattern in Go Encapsulate operations for queuing, audit history, and undo/redo while keeping Go error handling explicit. Singleton Pattern in Go Use sync.Once carefully for one-time initialization, and understand when dependency injection is a better fit.