Hablemos del elefante en la habitación de muchos proyectos Django: ese models.py que empezó pequeño y legible y que ahora es un monstruo de miles de líneas lleno de consultas ocultas, managers personalizados y efectos secundarios por todas partes. Cuando tocar algo da tanto miedo como una operación con un cuchillo de mantequilla, suele aparecer una solución aparentemente elegante: mover las consultas a un archivo selectors.py. Suena bien, suena limpio, pero en realidad es una trampa a medio plazo.
La idea de selectors nace de una buena intención: limpiar el modelo y mantener las vistas delgadas. Para proyectos pequeños esa aproximación funciona. Pero cuando la lógica crece, el modelo deja de ser solo una representación de datos y se transforma en un lugar donde conviven reglas de negocio, llamadas externas y lógica de acceso a datos. Trasladar consultas a selectors mejora la apariencia inicial, pero crea una segunda capa ambigua donde es muy fácil empezar a meter lógica de negocio.
Una alternativa más sostenible son los patrones Repository y Service. Un repositorio es una capa dedicada exclusivamente al acceso a datos. Su responsabilidad es clara: obtener, crear, actualizar y eliminar entidades siguiendo contratos definidos, sin mezclar reglas de negocio. Un servicio es la capa que orquesta flujos, valida reglas, gestiona transacciones y coordina otras dependencias como notificaciones o tareas asíncronas.
Con repositorios y servicios la separación es explícita. El repositorio responde por el como obtener ingredientes, el servicio por como preparar la receta. Esto facilita cambios futuros: si una consulta necesita optimización, se actualiza en un único lugar; si una regla de negocio cambia, se modifica en el servicio correspondiente sin tocar el acceso a datos.
Algunas ventajas prácticas: interfaz única y predecible para consultas, puntos de prueba claros donde sustituir implementaciones por fakes o mocks, y lugares naturales para añadir caching, logging o select_for_update cuando sea necesario. Esto convierte patrones en herramientas para mantener rendimiento y coherencia en equipos grandes.
Los selectors fallan porque no imponen límites. Es fácil empezar a añadir validaciones, notificaciones o pequeñas orquestaciones que luego se replican. En poco tiempo ese archivo es otra capa de negocio sin transacciones ni responsabilidades claras. Repositorios y servicios actúan como guardarraíles que hacen que la opción correcta sea también la cómoda.
Este patrón debe aplicarse en todos los puntos de entrada: acciones de administrador deben llamar a servicios, tasks de Celery deben llamar a servicios, comandos de gestión deben llamar a servicios. Así se centraliza la idempotencia, la lógica de reintentos y el control transaccional. Si una tarea se ejecuta dos veces, el servicio decide si continuar o abortar según el estado.
En la práctica del día a día surgen preguntas frecuentes. Está bien dejar pequeños helpers en el modelo si solo tocan el estado íntimo de esa entidad. No todo endpoint necesita un servicio: lecturas simples pueden ir repositorio directo a serializer. No es obligatorio tener un repo por cada modelo desde el inicio; empiece por agregados grandes, rutas críticas y queries pesadas. Si existen selectors, conviene que sean envoltorios finos sobre repositorios y nunca una fuente alternativa de verdad.
Más allá del código, estas capas facilitan la comunicación en equipos. Un product manager que informa de un fallo de pago sabe dónde mirar. Un desarrollador junior obtiene una guía clara sobre dónde ubicar lógica. Un revisor de código entiende qué patrones esperar. Además, los repositorios son buenos lugares para enseñar decisiones de rendimiento con ejemplos concretos en métodos reales en lugar de documentos largos que pocos leen.
En Q2BSTUDIO ayudamos a aplicar estas buenas prácticas en proyectos reales. Somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad, servicios cloud aws y azure y servicios inteligencia de negocio. Diseñamos arquitecturas limpias y escalables, desarrollamos soluciones de aplicaciones a medida y ofrecemos servicios de inteligencia artificial para empresas, incluyendo agentes IA y soluciones con power bi para inteligencia de negocio.
Si buscas ordenar tu código, mejorar mantenibilidad y escalar tu producto con criterios profesionales, Q2BSTUDIO puede acompañarte desde la auditoría del backend hasta la implementación de pipelines en la nube, pruebas de pentesting y soluciones de automatización. Aplicamos patrones como Repository y Service para que la claridad prevalezca sobre la conveniencia momentánea.
En resumen, evita la ilusión de que selectors son la solución definitiva. Prefiere claridad y límites bien definidos: modelos delgados, repositorios para acceso a datos y servicios para orquestar reglas. Esa disciplina ahorra horas de depuración, reduce errores y facilita el crecimiento del producto y del equipo.