MCP HubMCP Hub
SKILL·1DF8FA

go-architecture-review

eduardo-sl
업데이트됨 22 days ago
3 조회
68
9
68
GitHub에서 보기
디자인aiapidesign

정보

이 스킬은 Go 프로젝트 아키텍처를 검토하며, 패키지 구조, 의존성, 계층화, 모듈 경계를 분석합니다. 레이아웃 설계, 의존성 그래프 평가, 모놀리스를 모듈로 리팩터링할 때 유용합니다. 코드 스타일이나 API 설계(별도의 스킬이 존재함)가 아닌 아키텍처 검토에 사용하십시오.

빠른 설치

Claude Code

추천
기본
npx skills add eduardo-sl/go-agent-skills -a claude-code
플러그인 명령대체
/plugin add https://github.com/eduardo-sl/go-agent-skills
Git 클론대체
git clone https://github.com/eduardo-sl/go-agent-skills.git ~/.claude/skills/go-architecture-review

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서

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

GitHub 저장소

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

자주 묻는 질문

go-architecture-review Skill이란 무엇인가요?

go-architecture-review은(는) eduardo-sl이(가) 만든 Claude Skill입니다. Skill은 Claude가 필요할 때 불러오는 지침과 리소스를 묶어 추가 프롬프트 없이 go-architecture-review 관련 작업을 수행할 수 있게 합니다.

go-architecture-review은(는) 어떻게 설치하나요?

이 페이지의 설치 명령을 사용하세요. go-architecture-review을(를) Claude Code 플러그인으로 추가하거나 저장소를 skills 디렉터리에 복제한 다음 Claude를 다시 시작해 Skill을 불러옵니다.

go-architecture-review은(는) 어떤 카테고리에 속하나요?

go-architecture-review은(는) 디자인 카테고리에 속합니다.

go-architecture-review은(는) 무료로 사용할 수 있나요?

네. go-architecture-review은(는) AIMCP에 등록되어 있으며 무료로 설치할 수 있습니다.

연관 스킬

executing-plans
디자인

executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.

스킬 보기
requesting-code-review
디자인

이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.

스킬 보기
connect-mcp-server
디자인

이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.

스킬 보기
web-cli-teleport
디자인

이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.

스킬 보기