El diseño del sistema se basa en la arquitectura propuesta.

Component Design

La descomposición de componentes sigue directamente el Volatility Mapping de la arquitectura. Cada componente tiene una sola razón para cambiar, alineada a su área de volatilidad.

Frontend — Árbol de componentes:

src/ ├── config/ │ └── event.config.ts ← V1 · Toda la data del evento vive aquí │ ├── hooks/ │ └── useCountdown.ts ← V2 · Lógica del temporizador aislada │ ├── services/ │ └── registration.service.ts ← V6 · Capa de transporte HTTP │ ├── components/ │ ├── layout/ │ │ └── NavBar.tsx │ │ │ ├── sections/ ← V1 · V4 · Consumen event.config │ │ ├── HeroSection.tsx │ │ ├── EventInfoSection.tsx │ │ ├── GallerySection.tsx │ │ └── RegistrationSection.tsx │ │ │ ├── countdown/ ← V2 · Solo consume useCountdown │ │ └── CountdownTimer.tsx │ │ │ └── form/ ← V3 · V4 │ ├── RegistrationForm.tsx │ └── FormField.tsx │ └── App.tsx ← Orquestador, sin lógica de negocio

Backend — Estructura de módulos:

backend/ ├── app/ │ ├── main.py ← Entry point FastAPI, monta routers │ ├── config.py ← Settings (DB URL, CORS origins) │ │ │ ├── api/ │ │ └── v1/ │ │ └── registrations.py ← Router · solo HTTP concerns │ │ │ ├── schemas/ ← V3 · Pydantic · fuente de verdad de validación │ │ └── registration.py │ │ │ ├── services/ ← Lógica de negocio (Persist · Validate) │ │ └── registration.py │ │ │ ├── models/ ← V5 · SQLAlchemy ORM models │ │ └── registration.py │ │ │ └── db/ │ ├── base.py ← Declarative base │ └── session.py ← Engine + SessionLocal │ └── alembic/ ← Migraciones versionadas ├── env.py └── versions/ └── 001_create_registrations_table.py

API Design

Un solo endpoint. El contrato es simple porque el negocio es simple — no sobre-ingeniería.

Base URL: http://localhost:8000/api/v1

POST /registrations

Registra un asistente al evento.

Request

json

{ "name": "Ana Romero", "email": "ana@empresa.com", "message": "Me interesa el tema de IA aplicada a code review." }

Validaciones (Pydantic — fuente de verdad)

Response 201 Created

json