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.
- First
$golang-ddd-architecture - Then
$golang-ddd-refactor - Then
$golang-ddd-cqrs - Finally
$golang-ddd-infrastructure
- 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-dddwhen 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.