golang-design-patterns

Applies idiomatic Go design patterns for constructors, resource management, resilience, and architecture.

Updated Jun 15, 2026
One-click install
npx skills add https://github.com/2877389577/novels_ai_gen --skill golang-design-patterns-2877389577
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-design-patterns
Source: https://github.com/2877389577/novels_ai_gen/tree/main/.agents/skills/golang-design-patterns
Command: npx skills add https://github.com/2877389577/novels_ai_gen --skill golang-design-patterns-2877389577

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Go developers often struggle to choose the right design pattern for constructors, error flow, resource lifecycle, and application architecture, leading to over-engineered small projects or fragile large services. This Skill provides opinionated, idiomatic Go guidance so pattern choices match project scope and production requirements. ## Core Features & Use Cases - Constructor & Initialization Patterns: Functional options with error-returning validation, avoiding init(), enums starting at 1, compile-time interface checks, and package-level regexp compilation. - Resource & Resilience Patterns: Immediate defer Close(), runtime.AddCleanup over SetFinalizer, bounded channel-based connection pools, graceful shutdown with signal.NotifyContext, timeouts, and context-aware retry logic. - Architecture Guidance: Right-sized architecture selection (flat, layered, clean, hexagonal, DDD) with detailed reference guides, aggregate roots, bounded contexts, and anti-corruption layers. - Use Case: When designing a new Go HTTP service, ask the agent to review your constructor API and shutdown logic; it will recommend functional options, explicit initialization, and signal.NotifyContext-based graceful shutdown. ## Quick Start Ask the agent to design a Go HTTP server constructor with optional timeouts and connection limits using idiomatic patterns.

Frequently Asked Questions about golang-design-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement functional options in Go constructors?▼

Define an Option type as func(*Server), write With* functions returning Option, and accept variadic ...Option in the constructor. Set defaults first, then apply options, and return an error from options when validation can fail.

Should I use functional options or the builder pattern in Go?▼

Functional options are preferred because they scale better as APIs evolve with one function per option and no breaking changes. Use the builder pattern only when you need complex validation between configuration steps.

Why should I avoid init() for database setup in Go?▼

init() runs implicitly before main() and tests, cannot return errors, and creates hidden global dependencies that make testing unpredictable. Use explicit constructors like NewUserRepository(db) with dependency injection instead.

When should I use clean architecture vs hexagonal architecture in Go?▼

Hexagonal architecture fits services with multiple entry points (HTTP, gRPC, message consumers) using primary and secondary ports and adapters. Clean architecture fits medium-to-large services needing strict inward dependency rules across entity, use case, and adapter layers.

How do I implement graceful shutdown in a Go HTTP server?▼

Use signal.NotifyContext with SIGINT and SIGTERM, start the server in a goroutine, block on context cancellation, then call srv.Shutdown with a timeout context to drain requests. Close remaining resources like database connections afterward.

When should I not apply DDD or clean architecture to a Go project?▼

Avoid formal architectures for scripts and small CLIs under roughly 500 lines; a flat main.go with a few files is sufficient. Architecture complexity should match project scope, so start simple and refactor when complexity demands it.