Microservicio de pedidos extraído de un monolito, construido con Clean Architecture + Arquitectura Hexagonal sobre Spring Boot 3 y Java 21. Persiste en PostgreSQL y publica el evento OrderCreated en RabbitMQ.
- Docker y Docker Compose instalados
- Java 21 (solo para desarrollo local sin Docker)
docker compose up -dEsto arranca PostgreSQL, RabbitMQ y order-service. Gracias a los healthcheck + depends_on, la app no inicia hasta que la base de datos y el broker estén listos.
# Crear pedido
curl -X POST http://localhost:8080/api/v1/orders \
-H "Content-Type: application/json" \
-d '{"customerId": "cust-001", "totalAmount": 250.00}'
# Consultar pedido (usa el id devuelto al crearlo)
curl http://localhost:8080/api/v1/orders/{id}Abrir http://localhost:15672 (guest/guest) → Queues → order.created.queue.
./mvnw testLas pruebas usan H2 en memoria, por lo que no necesitan Docker ni infraestructura externa.
Estructura al estilo del libro Get Your Hands Dirty on Clean Architecture (Tom Hombergs):
src/main/java/org/example/orderservice/
├── common/ # Anotaciones estereotipo: @WebAdapter, @PersistenceAdapter, @UseCase
├── domain/ # Modelo y reglas de negocio puras (sin Spring/JPA/RabbitMQ)
├── application/ # Casos de uso (service) + puertos estrechos (port/in, port/out)
└── adapter/
├── in/web/ # Adaptador de entrada: REST (controller, DTOs, mapper, errores)
└── out/
├── persistence/ # Adaptador de salida: JPA (entity, repository, mapper, adapter)
└── messaging/ # Adaptador de salida: RabbitMQ (config, evento, publisher)
Regla de oro: el dominio define los puertos; los adaptadores los implementan. Los adaptadores de entrada solo dependen de input ports; los servicios solo de output ports. La lógica de negocio nunca se filtra a los adaptadores.
| Método | Ruta | Descripción |
|---|---|---|
| POST | /api/v1/orders |
Crear un pedido |
| GET | /api/v1/orders/{id} |
Consultar pedido por id |