Evaluación 6

Sustentación Final del Proyecto

Arquitectura Limpia y Demo en Vivo

20%
Proyecto Integrador
Fecha: 28 de mayo de 2026
⚠️ Requisitos Previos Obligatorios

TODAS las entregas E1-E5 deben estar completadas y funcionando. Esta evaluación integra todo el proyecto TaskFlow.

📚 Clases Relacionadas

Estas clases preparan los conocimientos necesarios para esta evaluación:

🔗 Prerequisitos obligatorios: Debes tener todas las evaluaciones E1E2E3E4E5 completadas antes de la sustentación final.

🎯 Objetivo de la Evaluación

Presentar el proyecto TaskFlow completo con Arquitectura Limpia y sustentar técnicamente todas las decisiones de diseño implementadas durante el curso.

Modalidad de Trabajo

Individual o en parejas (máximo 2 personas). Debe ser el mismo equipo de todas las entregas previas (E1-E5).

Formato de entrega: Repositorio GitHub final con todo el proyecto TaskFlow completo, README.md profesional con diagramas, y base de datos inicializada. Los dos miembros del equipo deben presentar juntos.

📋 Estructura de la Sustentación

La sustentación tiene una duración máxima de 15 minutos distribuidos en 3 partes:

1Defensa Arquitectónica (5 min)
Contenido Requerido
  • Explicar separación de capas: Domain → Application → Infrastructure → API
  • Justificar el uso de Repository Pattern, Inyección de Dependencias, DTOs
  • Mostrar diagrama de arquitectura (Mermaid o similar)
  • Explicar flujo de datos desde HTTP Request hasta la base de datos
💡 Tip: Prepara un diagrama claro que muestre las capas y sus dependencias. El docente preguntará sobre la dirección de las dependencias.
2Demo en Vivo (5 min)
Escenarios a Demostrar
  • CRUD completo: Crear usuario, proyecto, tareas en tiempo real
  • Persistencia: Reiniciar servidor y verificar que los datos persisten
  • HTMX: Demostrar interacciones sin recargas de página
  • Validaciones: Mostrar manejo de errores y validaciones
⚠️ Importante: Si el proyecto no ejecuta o tiene errores críticos durante la demo, la evaluación puede ser reprobada directamente.
3Prueba de Robustez (5 min)
El Docente Podrá:
  • Intentar "romper" el sistema con entradas inválidas
  • Hacer preguntas técnicas sobre decisiones de diseño
  • Revisar código fuente en vivo para validar implementación
  • Solicitar explicación de tests específicos

📁 Estructura de Archivos Requerida

El proyecto final debe seguir la siguiente estructura de Clean Architecture:

taskflow/ # === CAPA DE DOMINIO (Core) === ├── src/ │ ├── domain/ │ │ ├── entities/ │ │ │ ├── __init__.py │ │ │ ├── usuario.py │ │ │ ├── proyecto.py │ │ │ └── tarea.py │ │ ├── repositories/ │ │ │ ├── __init__.py │ │ │ └── interfaces.py # Interfaces abstractas │ │ └── value_objects/ │ │ └── email.py # # === CAPA DE APLICACIÓN (Use Cases) === │ ├── application/ │ │ ├── services/ │ │ │ ├── __init__.py │ │ │ ├── usuario_service.py │ │ │ ├── proyecto_service.py │ │ │ └── tarea_service.py │ │ └── dtos/ │ │ ├── __init__.py │ │ ├── usuario_dto.py │ │ └── tarea_dto.py # # === CAPA DE INFRAESTRUCTURA === │ ├── infrastructure/ │ │ ├── database/ │ │ │ ├── __init__.py │ │ │ ├── session.py │ │ │ └── models.py # Modelos SQLAlchemy │ │ ├── repositories/ │ │ │ ├── __init__.py │ │ │ ├── usuario_repo.py # Implementación JSON/SQL │ │ │ └── tarea_repo.py │ │ └── di/ │ │ └── container.py # Inyección de dependencias # # === CAPA DE API/PRESENTACIÓN === │ └── api/ │ ├── main.py # FastAPI app │ ├── routes/ │ │ ├── __init__.py │ │ ├── usuarios.py │ │ ├── proyectos.py │ │ └── tareas.py │ └── templates/ │ ├── base.html │ ├── usuarios/ │ ├── proyectos/ │ └── tareas/ # # === TESTING === ├── tests/ │ ├── unit/ │ ├── integration/ │ └── conftest.py # # === CONFIGURACIÓN === ├── alembic/ # Migraciones SQL ├── data/ # Persistencia JSON ├── requirements.txt ├── alembic.ini ├── pytest.ini └── README.md

📝 Entregables Finales Detallados

Repositorio GitHub
  • Código fuente completo con estructura Clean Architecture
  • Commits descriptivos y frecuentes
  • Sin archivos innecesarios (__pycache__, .pyc, .env)
  • Branch main con versión final
Tests Pasando
  • Ejecutar pytest sin errores
  • Cobertura mínima del 70%
  • Tests unitarios para entidades y servicios
  • Tests de integración para repositorios
README.md Profesional
  • Descripción del proyecto TaskFlow
  • Instrucciones de instalación y ejecución
  • Diagramas Mermaid de arquitectura
  • Ejemplos de uso de la API
Migraciones Alembic
  • alembic upgrade head ejecuta sin errores
  • Modelos sincronizados con la base de datos
  • Migraciones reversibles

💻 Ejemplo: Diagrama de Arquitectura

El README debe incluir un diagrama como este (puedes usar Mermaid en Markdown):

graph TB
    subgraph "API Layer"
        A[FastAPI Routes]
        B[Templates Jinja2]
    end

    subgraph "Application Layer"
        C[UsuarioService]
        D[TareaService]
        E[DTOs]
    end

    subgraph "Domain Layer"
        F[Usuario Entity]
        G[Tarea Entity]
        H[Repository Interfaces]
    end

    subgraph "Infrastructure Layer"
        I[UsuarioRepositorySQL]
        J[TareaRepositorySQL]
        K[Database Session]
    end

    A --> C
    A --> D
    B --> A
    C --> F
    D --> G
    C --> H
    D --> H
    I -.implements.-> H
    J -.implements.-> H
    I --> K
    J --> K

💻 Ejemplo: Inyección de Dependencias

El contenedor de dependencias debe permitir cambiar entre persistencia JSON y SQL fácilmente:

# src/infrastructure/di/container.py
from dependency_injector import containers, providers
from src.domain.repositories.interfaces import IUsuarioRepository, ITareaRepository
from src.infrastructure.repositories.usuario_repo import UsuarioRepositorySQL, UsuarioRepositoryJSON
from src.application.services.usuario_service import UsuarioService

class Container(containers.DeclarativeContainer):
    config = providers.Configuration()

    # Configuración de base de datos
    database_url = config.database_url

    # Selector de implementación según configuración
    usuario_repository = providers.Selector(
        config.storage_type,
        sql=providers.Factory(UsuarioRepositorySQL, session=database_url),
        json=providers.Factory(UsuarioRepositoryJSON, path="data/usuarios.json")
    )

    # Servicios de aplicación
    usuario_service = providers.Factory(
        UsuarioService,
        usuario_repo=usuario_repository
    )

📊 Rúbrica de Evaluación Final

Criterio Excelente (100%) Aceptable (70%) Insuficiente (40%) Peso
Funcionalidad Completa
Todas las features de E1-E5 integradas
CRUD completo, HTMX, persistencia dual, tests pasando Funcionalidad básica con algunos bugs menores Features faltantes o errores críticos 30%
Arquitectura Limpia
Separación de capas y dependencias
4 capas bien definidas, dependencias correctas (hacia adentro) Capas existentes pero con algunas dependencias cruzadas Arquitectura plana o dependencias invertidas 25%
Calidad de Código
Patrones, typing, documentación
Repository, DI, DTOs, type hints completos, PEP 8 Patrones parciales, algunos hints faltantes Código spaghetti, sin patrones evidentes 20%
Presentación y Demo
Claridad y manejo de preguntas
Demo fluida, respuestas técnicas correctas Demo con pausas, respuestas básicas Demo fallida o sin conocimiento técnico 15%
Documentación
README, diagramas, comentarios
README profesional con diagramas Mermaid README básico con instrucciones Sin README o documentación incompleta 10%

⚠️ Penalizaciones

Proyecto no ejecuta
-50% de la nota final
Tests con errores
-20% de la nota final
Falta README.md
-10% de la nota final
Evaluaciones previas incompletas
-15% por cada entrega faltante

🏆 Features Extra (Punto Adicional)

Bonus por Features Adicionales

Implementar cualquiera de las siguientes features otorga +1 punto adicional a la nota final (máximo 1 punto):

  • Dashboard con estadísticas: Gráficos de tareas completadas por proyecto
  • Autenticación JWT: Login/registro con tokens seguros
  • Notificaciones por email: Recordatorios de tareas pendientes
  • Tests E2E: Selenium o Playwright para flujos completos

📅 Checklist Pre-Sustentación

Antes de la Sustentación
  • Proyecto ejecuta sin errores (uvicorn api.main:app)
  • Tests pasando (pytest)
  • Base de datos inicializada (alembic upgrade head)
  • README.md completo con diagramas
Material a Preparar
  • Diagrama de arquitectura visible
  • Escenarios de demo ensayados
  • Respuestas preparadas para preguntas técnicas
  • Código limpio y organizado
← E5: SQL 🏠 Inicio