API de gestión de empleados
Prueba técnica resuelta con Clean Architecture, CQRS y pruebas por capa. El estándar con el que trabajo.
4
capas separadas
2
proyectos de pruebas
Una prueba técnica pedía un CRUD de empleados. La mayoría lo entrega como un controlador con acceso directo a la base de datos: funciona, pero no dice nada sobre cómo se trabaja en un proyecto real.
API en .NET con las capas separadas por la regla de dependencias, comandos y consultas resueltos con CQRS y MediatR, validación declarativa con FluentValidation, autenticación con JWT y todo empaquetado en Docker. Pruebas por capa y documentación de arquitectura incluida.
Separar comandos de consultas incluso en un CRUD pequeño. No porque el CRUD lo necesite, sino porque establece la estructura en la que el proyecto puede crecer sin reescribirse: cuando aparece la primera consulta con reportes o el primer comando con reglas, ya hay dónde ponerlos.
Entrega con documentación de arquitectura, diagramas de flujo de la petición y despliegue en contenedor. Sirve como muestra directa de mi estándar de trabajo.
Cómo se ve por dentro
Ejemplos ilustrativos de los patrones aplicados, con la razón de cada decisión.
Validación declarativa, fuera del controlador
public class CreateEmployeeValidator : AbstractValidator<CreateEmployeeCommand>
{
public CreateEmployeeValidator()
{
RuleFor(x => x.Email).NotEmpty().EmailAddress();
RuleFor(x => x.Name).NotEmpty().MaximumLength(100);
RuleFor(x => x.CompanyId).GreaterThan(0);
}
}Las reglas de entrada no se mezclan con la lógica de negocio ni con el controlador. Se leen de corrido y se prueban solas.
Ejemplo ilustrativo del patrón aplicado; no es código de ningún producto.Stack del proyecto
¿Necesitas algo parecido?
Cuéntame tu caso y te digo con franqueza si es viable y cuánto toma.
Hablemos