golang-ddd-infrastructure
Golang 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.
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
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.
10golang-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.
10