About golang-ddd-infrastructure
A skill for Go teams shaping infrastructure and delivery around service boundaries. It focuses on explicit wiring, deterministic testing, CI, and visible security rules.
Key features
- 01Declarative infrastructure
- 02Explicit service configuration
- 03Layered test guidance
- 04Deterministic CI practices
- 05Explicit security boundaries
Use cases
- 01Organizing Terraform modules
- 02Planning service endpoint and credential configuration
- 03Designing integration and component tests
- 04Reviewing CI and privileged operations
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ joeyave/ golang-ddd-skills --skill golang-ddd-infrastructureAfter installing, type/golang-ddd-infrastructurein Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
agents/openai.yamlreferences/infra-and-delivery.mdtesting-and-security.mdDetails
From the project READMEGolang DDD Infrastructure
Use this skill when infrastructure or delivery work must reinforce the service architecture instead of leaking into the domain model or weakening safety guarantees.
Start Here
- Treat infrastructure as support for the service design, not the place where missing application boundaries are patched over.
- Use this skill after the service boundaries are at least roughly clear, or when CI, auth, or repository design is now blocking development.
Workflow
- Keep infrastructure declarative.
- Prefer Infrastructure as Code over click-ops.
- Group repeated infrastructure shapes into Terraform modules or similarly clear abstractions.
- Wire services explicitly.
- Pass service endpoints, credentials, and environment differences through well-named configuration.
- Avoid smuggling infrastructure-specific details into domain packages.
- Make the test pyramid real.
- Keep domain tests fast and local.
- Use integration tests for adapters and transaction behavior.
- Use component tests for one service with mocked externals.
- Keep end-to-end coverage selective and avoid making it the default safety net.
- Design for stable CI.
- Run tests automatically in the pipeline.
- Keep non-unit tests parallel-safe and deterministic.
- Avoid
sleep-based synchronization; wait on explicit readiness or eventual conditions.
- Keep security explicit.
- Do not use fake users or hidden context values for privileged internal updates.
- Prefer explicit roles, commands, or repository methods with names that signal security implications.
- Keep service-to-service authentication and permissions visible in configuration and adapter code.
- Preserve architectural boundaries.
- Infrastructure may compose ports and adapters, but it must not force the domain to know about deployment details.
- If a repository or handler needs special internal behavior, name it explicitly instead of adding magic flags.
Use These References
- Read references/infra-and-delivery.md for Terraform, Cloud Run, and CI patterns that fit this style.
- Read references/testing-and-security.md for test architecture and secure-by-design repository guidance.
Deliverables
- infrastructure that can be reviewed as code,
- explicit service wiring and permissions,
- a CI path that runs the right tests automatically,
- integration and component tests that are deterministic,
- internal operations with explicit security boundaries.
Comments
Markdown supported