En el desarrollo de software, la velocidad no es escribir código rápido; es tener que tomar la menor cantidad de decisiones estructurales posibles una vez que la lógica de negocio empieza a fluir. Django se vende como el framework para "perfeccionistas con deadlines", pero si te quedas solo con la configuración por defecto, pronto te encuentras luchando contra el framework en lugar de apoyarte en él.
Tras años de iterar en diversos entornos, he consolidado un boilerplate mental que elimina la fricción inicial y establece un estándar de producción desde el minuto uno. Aquí te comparto las decisiones de arquitectura que tomo antes de escribir la primera vista.
1. La base: Estructura de archivos limpia
El comando por defecto django-admin startproject suele generar carpetas anidadas redundantes. Mi primer paso es siempre aplanar la jerarquía:
mkdir LMS && cd LMS
python -m venv venv
source venv/bin/activate
django-admin startproject core .Esto coloca el archivo manage.py en la raíz real del proyecto, facilitando la gestión de contenedores y despliegues.
2. Ajustes de entorno: El fin de settings.py
Un solo archivo de configuración es un suicidio técnico para un proyecto que escalará. Lo primero que hago es transformar settings.py en un paquete:
- base.py: Configuraciones universales (Apps, Middlewares).
- local.py: Debug activo, bases de datos de desarrollo y herramientas como django-debug-toolbar.
- production.py: Seguridad estricta, manejo de archivos estáticos en S3 y logs persistentes.
En este punto, centralizo los recursos. Configuro un único directorio de templates en la raíz ('DIRS': [os.path.join(BASE_DIR, 'templates')]) para evitar que las plantillas queden dispersas y ocultas dentro de cada aplicación.
3. El control total: Formularios y Tailwind CSS
Aquí es donde la mayoría de los desarrolladores pierden tiempo. Django es excelente manejando la lógica de formularios, pero su HTML por defecto suele ser tosco.
Para solucionar esto, utilizo una combinación de Custom Form Renderers y una arquitectura de constantes de estilo:
- Habilitar la personalización: En el settings, defino FORM_RENDERER = 'django.forms.renderers.TemplatesSetting'. Esto me permite sobrescribir los templates originales de Django dentro de mi carpeta raíz de plantillas.
- Abstracción de estilos: Creo un archivo form_styles.py dentro de una carpeta de constantes. En lugar de escribir clases de Tailwind en cada formulario, defino constantes de diseño. Si el branding cambia, lo cambio en un solo lugar, no en cincuenta formularios.
4. El stack visual: Tailwind y Alpine.js
No utilizo librerías de terceros que "integren" Tailwind a medias. Prefiero el control nativo. Instalo Tailwind vía npm en una carpeta /tailwind en la raíz. El proceso de build envía el CSS procesado a una carpeta global de /static que también contiene mis recursos de Alpine.js y fuentes locales.
Esto garantiza que el frontend sea ligero y que el equipo tenga total libertad para extender el diseño sin pelear con abstracciones innecesarias.
5. Arquitectura de Apps: Más allá de lo básico
Cuando una aplicación crece, los archivos models.py o views.py se vuelven inmanejables. Mi regla es simple: si el archivo supera las 300 líneas, lo convierto en un paquete. Divido la lógica en archivos específicos y uso un __init__.py para mantener la interfaz de importación limpia.
Además, he implementado dos capas adicionales:
- Service Layer: Para lógica que no pertenece estrictamente al modelo ni a la vista (como un servicio de despacho de correos o integraciones con APIs externas).
- Dashboard Custom: Aunque el admin de Django es potente, para el usuario final o el cliente siempre construyo una app /dashboard dedicada. El admin es para nosotros; el dashboard es para el negocio.
6. La mentalidad de despliegue
El control de versiones refleja el flujo de trabajo: main para estabilidad, develop para integración y deploy para el pipeline de producción. Cada rama tiene un propósito claro, reduciendo los errores de integración de último minuto.