quarkus-service-architecture

# Quarkus Service Architecture ## Overview Quarkus is the default Java stack: fast startup, low memory, native-image friendly — the closest Java gets to Go's operational profile. Build services in clean layers so the framework stays at the edges and the domain stays plain Java. **Core principle:** Framework annotations live at the boundaries (resources, repositories). The domain and services are plain classes you can unit-test without booting Quarkus. ## Layers | Layer | Responsibility | Quarkus surface | |-------|----------------|-----------------| | Resource | HTTP in/out, validation, status codes | `@Path`, JAX-RS (`@GET`/`@POST`), `@Valid` | | Service | Use-case orchestration, business rules | `@ApplicationScoped` CDI bean, constructor-injected | | Domain | Entities, value objects, invariants | plain Java, no annotations driving behavior | | Repository | Persistence | Panache (`PanacheRepository`) or JPA | Dependencies point inward: resource → service → domain; repository implements a port the service depends on. A resource never contains business logic; a service never touches `RoutingContext` or JAX-RS types. ## Patterns - **Constructor injection**, not field injection: `public TaskService(TaskRepository repo)`. Constructor injection is testable without CDI and makes dependencies explicit. - **DTOs at the edge**: resources accept/return DTOs (records), map to/from domain in the service. Never expose JPA entities directly over HTTP. - **Bean Validation** on reque...