MCP HubMCP Hub
SKILL·1DF8FA

go-architecture-review

eduardo-sl
Mis à jour 27 days ago
3 vues
69
9
69
Voir sur GitHub
Designaiapidesign

À propos

Cette compétence examine l'architecture de projets Go, en analysant la structure des packages, les dépendances, la stratification et les limites des modules. Elle est utile lors de la conception d'organisations, de l'évaluation de graphes de dépendance ou de la refactorisation de monolithes en modules. Utilisez-la pour des revues d'architecture, mais pas pour le style de code ou la conception d'API, qui relèvent de compétences distinctes.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add eduardo-sl/go-agent-skills -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/eduardo-sl/go-agent-skills
Git CloneAlternatif
git clone https://github.com/eduardo-sl/go-agent-skills.git ~/.claude/skills/go-architecture-review

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

Go Architecture Review

Good architecture makes the next change easy. Bad architecture makes every change scary.

Operating Modes

Pick the mode that matches the request before starting:

  • Layout review (default) — assess an existing codebase against the sections below and report violations with severity.
  • Refactor plan — same assessment, but the deliverable is an ordered migration plan (smallest safe steps first), not just findings.
  • New service consultation — asked "how should I structure X": apply sections 1-3 as prescriptive guidance instead of review checks.

Auditing Large Codebases

For repositories with many packages, build the dependency picture before judging it:

  1. Map the module: go list ./... for packages, then import statements to trace dependency direction.
  2. Run independent passes: (a) layout vs section 1, (b) dependency direction vs section 2, (c) wiring and config vs sections 3+5, (d) package design vs section 4.
  3. If your environment supports delegating work to parallel sub-agents or tasks, assign each pass to one; synthesize at the end — dependency findings often explain layout findings.
  4. Cite package paths and file.go:line in every finding.

1. Standard Project Layout

myproject/
├── cmd/                    # Main applications (one dir per binary)
│   ├── api-server/
│   │   └── main.go
│   └── worker/
│       └── main.go
├── internal/               # Private packages — cannot be imported externally
│   ├── domain/             # Core business types (entities, value objects)
│   │   ├── user.go
│   │   └── order.go
│   ├── service/            # Business logic (use cases)
│   │   ├── user.go
│   │   └── order.go
│   ├── store/              # Data access (repositories)
│   │   ├── postgres/
│   │   │   └── user.go
│   │   └── redis/
│   │       └── cache.go
│   ├── handler/            # HTTP/gRPC handlers (adapters)
│   │   └── user.go
│   └── config/             # Configuration loading
│       └── config.go
├── pkg/                    # Public packages (use sparingly)
│   └── httputil/
│       └── response.go
├── migrations/             # Database migrations
├── api/                    # API definitions (OpenAPI, proto files)
├── go.mod
├── go.sum
└── Makefile

Key Rules:

  • internal/ enforces encapsulation at the compiler level. Use it aggressively.
  • pkg/ is for genuinely reusable packages. When in doubt, use internal/.
  • cmd/ main packages should be thin — wire dependencies and call Run().
  • One main.go per binary, minimal logic inside.

2. Dependency Direction

Dependencies MUST flow inward. Domain core has zero external dependencies:

handlers → services → domain ← stores
    ↓          ↓                  ↓
  (net/http)  (pure Go)     (database/sql)

Rules:

  • domain/ imports NOTHING from the project. No store, no handler, no config.
  • service/ depends on domain/ types and interfaces, NOT on concrete stores.
  • handler/ depends on service/ interfaces.
  • store/ implements interfaces defined in service/ or domain/.
  • Circular dependencies are a 🔴 BLOCKER. The compiler catches them, but design should prevent them.
// ✅ Good — service defines the interface it needs
// internal/service/user.go
type UserStore interface {
    GetByID(ctx context.Context, id string) (*domain.User, error)
    Create(ctx context.Context, user *domain.User) error
}

type UserService struct {
    store UserStore // depends on interface, not postgres.Store
}

// internal/store/postgres/user.go
type Store struct { db *sql.DB }

// Implements service.UserStore without importing the service package
func (s *Store) GetByID(ctx context.Context, id string) (*domain.User, error) { ... }

3. Main Package Wiring

main.go is the composition root. Wire everything here:

func main() {
    cfg := config.Load()
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

    db, err := sql.Open("postgres", cfg.DatabaseURL)
    if err != nil {
        logger.Error("connect db", slog.Any("error", err))
        os.Exit(1)
    }
    defer db.Close()

    // Wire dependencies
    userStore := postgres.NewUserStore(db)
    userService := service.NewUserService(userStore)
    userHandler := handler.NewUserHandler(userService, logger)

    // Setup router
    r := chi.NewRouter()
    r.Mount("/api/v1/users", userHandler.Routes())

    // Run server
    srv := &http.Server{Addr: cfg.Addr, Handler: r}
    // ... graceful shutdown
}

Avoid dependency injection frameworks. Go's explicit wiring is a feature. If wiring gets complex, use Google's wire for compile-time DI code generation.

4. Package Design Principles

One package = one purpose

// ✅ Good — clear purpose
package orderservice  // business rules for orders
package postgres      // PostgreSQL data access
package httphandler   // HTTP transport layer

// ❌ Bad — grab-bag packages
package utils    // what ISN'T a util?
package common   // everything and nothing
package models   // types without behavior

Avoid package stuttering

// ❌ Bad — package name repeated in type
package user
type UserService struct{} // user.UserService

// ✅ Good
package user
type Service struct{} // user.Service

Package cohesion over size

A package with 20 related files is better than 20 packages with 1 file each. Split packages when they have distinct responsibilities, not when they get big.

5. Configuration

type Config struct {
    Addr        string        `env:"ADDR" envDefault:":8080"`
    DatabaseURL string        `env:"DATABASE_URL,required"`
    LogLevel    string        `env:"LOG_LEVEL" envDefault:"info"`
    Timeout     time.Duration `env:"TIMEOUT" envDefault:"30s"`
}

Rules:

  • All config from environment variables (12-factor).
  • Validate at startup, fail fast with clear messages.
  • No config scattered across packages — centralize in internal/config.
  • Never hardcode values. Not even "just for now."

6. Init Functions

Avoid init(). It runs implicitly, makes testing harder, and creates hidden dependencies.

// ❌ Bad — hidden side effects
func init() {
    db, _ = sql.Open("postgres", os.Getenv("DB_URL"))
}

// ✅ Good — explicit initialization
func NewStore(dsn string) (*Store, error) {
    db, err := sql.Open("postgres", dsn)
    if err != nil {
        return nil, fmt.Errorf("open db: %w", err)
    }
    return &Store{db: db}, nil
}

Exception: registering drivers or codecs is acceptable in init():

func init() {
    sql.Register("custom", &CustomDriver{})
}

Architecture Review Checklist

  • 🔴 No circular dependencies between packages
  • 🔴 Domain types have zero infrastructure dependencies
  • 🔴 No business logic in cmd/ main packages
  • 🔴 No init() with side effects (DB connections, HTTP calls)
  • 🟡 internal/ used for project-private packages
  • 🟡 Interfaces defined at the consumer, not the producer
  • 🟡 Configuration centralized and validated at startup
  • 🟡 Dependency direction flows inward (handlers → services → domain)
  • 🟢 Package names are short, singular, descriptive
  • 🟢 No utils/, common/, helpers/ packages
  • 🟢 Main package is a thin composition root

Dépôt GitHub

eduardo-sl/go-agent-skills
Chemin: skills/(architecture)/go-architecture-review
0
FAQ

Questions fréquentes

Qu’est-ce que le Skill go-architecture-review ?

go-architecture-review est un Skill Claude créé par eduardo-sl. Un Skill regroupe des instructions et des ressources que Claude charge à la demande pour effectuer des tâches liées à go-architecture-review sans consigne supplémentaire.

Comment installer go-architecture-review ?

Utilisez les commandes d’installation de cette page : ajoutez go-architecture-review à Claude Code comme plugin ou clonez son dépôt dans votre dossier skills, puis redémarrez Claude pour charger le Skill.

À quelle catégorie appartient go-architecture-review ?

go-architecture-review appartient à la catégorie Design.

go-architecture-review est-il gratuit ?

Oui. go-architecture-review est référencé sur AIMCP et son installation est gratuite.

Compétences associées

executing-plans
Design

Utilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.

Voir la compétence
requesting-code-review
Design

Cette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.

Voir la compétence
connect-mcp-server
Design

Cette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.

Voir la compétence
web-cli-teleport
Design

Cette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.

Voir la compétence