本文へ移動
cccskills
無料GitHub で公開

go-hexagonal-architecture

Use when adding a use case, port, repository or adapter in a Go service — where each piece goes, how errors and transactions cross layers, and how to check the import direction

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Hexagonal Architecture in Go

Detect the repo's layout first

get_repo_tree   # look for domain/port/application/adapter-named folders

Follow the repository's own names for these folders (internal/core, internal/service, whatever it already uses) — don't rename them to match this skill. Never restructure a repository that is not hexagonal in a feature task. If the repo has no layering at all, follow its existing flat/package-by-feature style instead of introducing hexagonal boundaries unasked.

Layers

  • Domain (innermost): entities, value types, domain errors. Imports nothing from the outer layers — no Fiber, no pgx, no HTTP, no JSON tags driving behavior.
  • Ports: interfaces (e.g. internal/port) describing what the application needs (repositories, clients) and offers (services).
  • Application: use-case services orchestrating domain logic through ports. Depends on domain and ports only.
  • Adapters: implementations at the edge — HTTP handlers, PostgreSQL repositories, external clients. Adapters import inward; nothing imports an adapter.

Rules

  • Dependency injection via constructors: NewService(store port.Store, ...). No globals, no init()-time wiring (Uber: "Avoid init()", "Exit in Main").
  • Cross-layer calls go through ports. A service never touches pgx directly; a handler never contains business logic.
  • New behavior starts with the port interface and its domain types, then the service, then the adapter — the test for the service uses a fake or mock of the port (mockery-suite-tests).
  • When adding a dependency, ask: does the domain need to know this exists? If yes, model it as a port; if no, keep it inside the adapter.
  • Verify interface compliance at compile time (Uber): var _ port.TaskStore = (*PGTaskStore)(nil) next to the adapter's constructor — a missing method fails the build, not a runtime wiring panic.
  • Copy slices and maps at boundaries (Uber) — a port implementation that hands back its internal slice lets the caller mutate state it doesn't own.

Worked Example: "Archive a project"

  1. Domain errors: domain.ErrNotFound, domain.ErrConflict (sentinel errors the adapters translate into and the handler's central mapper translates out of).
  2. Port: port.ProjectStore with Archive(ctx context.Context, id uuid.UUID) error.
  3. Service + test: the use case calls the port; the test uses the port's mock/fake — no database in this test.
  4. Postgres adapter: translates driver errors into domain errors — errors.Is(err, pgx.ErrNoRows) → domain.ErrNotFound; pgErr.Code == "23505" → domain.ErrConflict. This translation happens in the adapter, never in the handler or service.
  5. Compile-time check: var _ port.ProjectStore = (*PGProjectStore)(nil) beside the constructor.
  6. Handler: maps through the one central error handler (fiber-rest-api) — no case-by-case mapping here.

Transactions across ports

Model the transaction boundary as a port, not a leaked *sql.Tx/pgx.Tx: port.TxRunner with WithinTx(ctx context.Context, fn func(ctx context.Context) error) error. The Postgres adapter puts the pgx.Tx into the returned ctx; repository adapters use the tx-in-context when present, falling back to the pool otherwise. The transaction boundary belongs to the use case (application layer), which decides what must commit together — never to a repository method.

Wiring

Constructors are called from main/a wiring package only — no package-level mutable globals holding dependencies (Uber "Avoid Global State").

Verify the import direction

go list -deps ./internal/domain/... ./internal/application/... | grep -E '/internal/adapter|gofiber|jackc/pgx|database/sql'

Adjust the paths to the repo's actual package names. Must print nothing — any hit is a boundary violation.

Smell Checklist

  • A framework/driver import (gofiber/fiber, jackc/pgx, database/sql) anywhere under domain or application → boundary violation.
  • A struct with both business rules and SQL strings → split into service + repository adapter.
  • A handler longer than ~30 lines → logic belongs in the application service.
  • A port method returning a framework type (*fiber.Ctx, *sql.Rows) instead of domain types.
  • A repository adapter test that mocks the SQL driver instead of running against real Postgres.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

makifbaysal のスキルをすべて見る

このスキルの問題を報告する