What this prompt does
This prompt asks the AI to scaffold a production-ready Spring Boot [spring_version] microservice for [domain], shaped so it is deployable from day one. It produces a hexagonal ports-and-adapters structure, REST controllers in [api_style] with proper status codes, JPA entities on [db_type] with Flyway migrations, Spring Security using [auth_method], a global exception handler returning RFC 7807 Problem Details, OpenAPI docs via springdoc, structured logging with MDC, health checks and metrics with Micrometer plus [observability_stack], a Docker multi-stage build with docker-compose, and integration tests using Testcontainers — with dev, test, and prod profiles in application.yml.
The structure works because a clean baseline saves weeks of rework. By specifying your real [domain], [db_type], and [auth_method], the AI produces a service that is production-shaped before any feature code lands. The hexagonal layout keeps business logic independent of frameworks, and the observability and Testcontainers steps mean the service is testable and operable from the first commit. The dev, test, and prod profiles in application.yml also separate configuration cleanly, so the same artifact runs in each environment without code changes — only the active profile differs.
When to use it
- You are starting a new Spring Boot microservice and want a clean, production-shaped baseline.
- You want hexagonal architecture so domain logic stays decoupled from web and persistence concerns.
- You need security, observability, and migrations wired in before writing feature code.
- You want integration tests against a real database via Testcontainers rather than mocks.
- You need consistent error responses using RFC 7807 Problem Details across the service.
- You want Docker and docker-compose ready so the service runs the same locally and in CI.
Example output
Expect a project skeleton: package structure for ports and adapters, REST controllers, JPA entities with Flyway scripts, a SecurityConfig for [auth_method], a global exception handler, springdoc setup, Micrometer wiring to [observability_stack], a multi-stage Dockerfile, docker-compose with the database, Testcontainers-based integration tests, and profile-specific application.yml files. It is a runnable, deployable baseline rather than a single class, with the structured-logging MDC context and health endpoints already in place so you can observe the service the moment it starts.
Pro tips
- Name
[domain]concretely so the generated entities, controllers, and package names reflect your real bounded context. - Match
[db_type]to production, since Flyway scripts and JPA column types differ between PostgreSQL, MySQL, and others. - Set
[auth_method]precisely (for example, OAuth2 Resource Server with JWT) so SecurityConfig validates tokens correctly. - Keep
[api_style]honest about whether you actually want HATEOAS, as it adds real complexity you must maintain. - Confirm the
[observability_stack]matches your tooling so the metrics and tracing exporters target the right backends. - Iterate by asking it to add one feature slice end to end (controller to adapter to migration) to validate the hexagonal layering.
