Expedientes académicos y títulos
Gestión de expedientes académicos del grupo Proeduca y generación de títulos oficiales: APIs .NET 8, Docker y frontend Angular en producción, con Clean Architecture y DDD.
Problema
Los expedientes académicos y la emisión de títulos oficiales cruzan instituciones del grupo Proeduca. El riesgo no es elegir un framework: es que el dominio se acople a la infraestructura y un fallo en un expediente o en un título deje el proceso parado.
Solución
Un dominio de expedientes y títulos delimitado con Clean Architecture y DDD, APIs en .NET 8 contenedorizadas con Docker, CQRS con Mediator, y un pipeline (TeamCity, Azure DevOps, SonarQube, GitFlow) que no deja pasar a main sin tests ni revisión.
Resultados
80 %
Cobertura de tests unitarios
2020 — actualidad
En el puesto
Expedientes y títulos en producción
Producto
- Presentación
API y frontend
ASP.NET Core y Angular 18. Adaptadores: no mandan sobre el dominio.
- Aplicación
Casos de uso
CQRS con Mediator. Un comando o una consulta, no un controlador gordo.
- Dominio
Expedientes y títulos
Entidades y reglas de negocio. Cero dependencias de framework.
- Infraestructura
Datos y Docker
Entity Framework, SQL Server y .NET 8. Docker para paridad dev/prod.
Cómo llega a producción
- TeamCity
- Azure DevOps
- Docker
- SonarQube
- GitFlow
- Code review
Stack tecnológico
- .NET 8
- C#
- ASP.NET Core
- Entity Framework
- Angular 18
- SQL Server
- Docker
- Azure DevOps
- TeamCity
- SonarQube
El trabajo que lidero en Proeduca no es un portfolio público: es la gestión de expedientes académicos del grupo y la generación de títulos oficiales. Lidero técnicamente un equipo Scrum que entrega dominio, APIs .NET 8 y frontend Angular, todo en producción y contenedorizado con Docker.
Este caso cuenta las decisiones que se pueden decir en voz alta. El código se queda en Proeduca.
Qué había que sostener
Un expediente no falla en abstracto: falla cuando no se puede matricular, evaluar o emitir un título. El trabajo de estos años ha sido modernizar ese dominio sin cortar el servicio, con un núcleo que se pueda mantener y un pipeline que no deje pasar a main lo que no está revisado.
Decisiones
Clean Architecture y DDD. El dominio de expedientes y títulos no depende de ASP.NET, ni de Entity Framework, ni de Angular. Las reglas de negocio viven en el núcleo; la API y el frontend son adaptadores. La promesa no es usar el patrón de moda: es que el código escrito hoy lo pueda mantener otra persona dentro de dos años.
CQRS con Mediator. Los casos de uso entran por un comando o una consulta, no por un controlador gordo. Mediator desacopla la orquestación de la infraestructura: el handler habla con el dominio y con repositorios, no con detalles de HTTP ni de SQL.
.NET 8 y Docker. El backend corre sobre ASP.NET Core actual. Docker iguala el entorno de desarrollo y el de producción: lo que pasa los tests en el pipeline es lo que se despliega.
Delivery. TeamCity y Azure DevOps ejecutan el pipeline. SonarQube y GitFlow, con code review por pull request, son la puerta de entrada a main. La cobertura de tests unitarios se sostiene al 80 %.
IA, con el alcance que tiene
La IA entra en el ciclo de desarrollo —Claude, Codex, OpenCode— donde acorta el camino. La automatización de procesos internos va con n8n. Ni una ni otra sustituyen el criterio de quien mergea, ni son un microservicio de documentos académicos en producción: eso no consta aquí.
Galería
Qué aprendí
- → El code review por pull request como única puerta a main es más barato que un incidente en un título o en un periodo de matrícula.
- → La cobertura al 80 % no es un número de sprint: es una línea que el pipeline sostiene.
- → Mediator y DDD no son ceremonia. Son el límite que impide que el frontend o Entity Framework dicten el dominio.
- → Docker iguala desarrollo y producción; .NET 8 es el suelo, no el eslogan.
- → La IA en el ciclo de desarrollo (Claude, Codex, OpenCode) acorta el camino; n8n cubre la automatización interna. Ni una ni otra sustituyen el criterio de quien mergea.