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
- 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.
- 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.
- Use this default order when multiple skills apply.
More from joeyave/golang-ddd-skills
golang-ddd-architecture
Design and refactor Go service architecture for DDD-style systems. Use when a Go codebase needs explicit ports/app/domain/adapters boundaries, dependency rules, interface placement, composition-root dependency injection, separate transport and database models, or help deciding whether DDD, Clean Architecture, or CQRS are justified.
13golang-ddd-refactor
Refactor existing Go code toward a behavior-first, invariant-protecting domain model. Use when business rules live in handlers or repositories, shared structs couple DB and API models, entities expose setters or mutable public fields, or a service needs domain methods, constructors, private state, repository update closures, and focused domain tests.
12golang-ddd-cqrs
Structure Go application logic with pragmatic CQRS. Use when command and query concerns are mixed, handlers are hard to test, one application service is becoming wide, or a Go service needs business-oriented command and query naming, separate handlers, thin ports, narrow consumer-owned interfaces, and guidance on when CQRS is or is not worth the cost.
10golang-ddd-infrastructure
Support Go services by keeping infrastructure, security boundaries, and automated tests aligned with the application architecture. Use when working on Terraform, Cloud Run, Cloud Build or CI, docker-compose environments, integration or component test setup, repository authorization boundaries, service-to-service authentication, or secure internal operations.
10