# Golang Ddd

> Entry-point router for Go architecture and refactoring tasks focused on DDD-style services. Use when working on a Go service and you want one skill to decide whether the task is primarily about architecture boundaries, domain-first refactoring, pragmatic CQRS, or delivery and test support. This skill should select one or more companion skills and apply them in the right order.

- Skill: `joeyave/golang-ddd` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add joeyave/golang-ddd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/joeyave/golang-ddd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: joeyave (https://skillmd.com/u/joeyave)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/joeyave/golang-ddd

---


# Golang DDD

Use this as the default manual entry point when the task is “make this Go service easier to evolve without over-engineering” but the exact technique is not yet obvious.

## Routing Workflow

1. Start by classifying the task.
- If the main problem is package structure, layer boundaries, shared models, dependency direction, or import cycles, start with `$golang-ddd-architecture`.
- If the main problem is business rules hidden in handlers, repositories, or mutable structs, start with `$golang-ddd-refactor`.
- If the main problem is a wide application service, CRUD names, mixed reads and writes, or handler-specific dependency sprawl, start with `$golang-ddd-cqrs`.
- If the main problem is Terraform, CI, test strategy, service auth, or secure internal operations, start with `$golang-ddd-infrastructure`.

2. Combine skills when the task spans layers.
- Architecture + domain refactor is the most common pair for rescue refactors.
- Domain refactor + CQRS fits when write-side business logic already exists and the app layer is too wide.
- Architecture + infrastructure fits when CI or deployment work is exposing missing boundaries.
- Infrastructure may follow any of the others when tests, auth, or delivery constraints need to be aligned with the code structure.

3. Use this default order when multiple skills apply.
- First `$golang-ddd-architecture`
- Then `$golang-ddd-refactor`
- Then `$golang-ddd-cqrs`
- Finally `$golang-ddd-infrastructure`

4. Keep the solution proportional.
- Do not force CQRS into simple CRUD.
- Do not split models or layers more than the current complexity needs.
- Prefer the smallest change that makes the code safer to modify.

## Manual Invocation Tips

- Use `golang-ddd` when you are unsure which specialized skill is the right one.
- Use a specialized skill directly when the problem is already obvious.
- If the request asks for a domain-oriented cleanup or refactor without more detail, start here.

## Companion Skills

- `$golang-ddd-architecture`
- `$golang-ddd-refactor`
- `$golang-ddd-cqrs`
- `$golang-ddd-infrastructure`

## Deliverables

- a clear choice of which companion skill or skill sequence to use,
- a scoped plan that matches the actual complexity,
- avoidance of over-engineering for simple services.