Que cada proyecto nazca
con la misma estructura.
laravel-module-maker genera la arquitectura completa de un módulo —capas,
permisos, migraciones, vistas y pruebas— siguiendo un único patrón, el mismo en todos los
proyectos de la casa. Lo que hoy depende de la memoria de cada desarrollador pasa a depender
de un comando.
El problema que resuelve
Sin un generador, cada módulo es una decisión nueva
No es un problema de talento: es un problema de repetición. Un equipo que escribe la misma estructura a mano, una y otra vez, en proyectos distintos, termina con variaciones — y esas variaciones son las que cuestan tiempo seis meses después, cuando alguien tiene que entrar a un módulo que no escribió.
Sin el generador
- Cada desarrollador decide dónde va cada archivo — y decide distinto
- Las pruebas se agregan si alcanza el tiempo, no porque el proyecto las exija
- Un proyecto nuevo empieza copiando el anterior, con lo que ese anterior tenía de bueno y de malo
- El error de permisos o de migración se descubre en el despliegue, no antes
Con el generador
- La estructura de capas la escribe el comando, siempre igual
- El contrato de pruebas nace junto con el módulo, no aparte
- Un proyecto nuevo arranca con la versión vigente del patrón, no con la costumbre de quien lo empezó
- Un diagnóstico revisa el proyecto antes de generar o desplegar, y dice qué corregir
Cómo funciona, a nivel de proceso
Cuatro pasos, sin que nadie tenga que recordarlos
El generador no reemplaza el criterio del equipo de TI: fija el andamiaje para que ese criterio se aplique siempre igual, sin depender de que alguien se acuerde del paso que hoy se salta.
Diagnosticar
Antes de generar nada, innodite:doctor revisa que el proyecto esté en condiciones. Si algo falta, lo dice — con la corrección, no solo el error.
Generar
Un comando escribe el módulo completo: capas, permisos, migraciones y vistas, y lo deja declarado en el orden en que se va a desplegar.
Desplegar
Un único comando levanta esquema, datos y permisos en el orden correcto, para el proyecto entero o para un cliente puntual si es multiempresa.
Probar
El contrato de pruebas corre sobre una copia real del esquema, nunca sobre la base de producción, y se detiene en el primer nivel que falla.
Ventajas para la empresa
Lo que cambia en cómo se entregan los proyectos
Un desarrollador que conoce un proyecto, conoce todos
La estructura es la misma en cada proyecto de la casa. Mover a alguien de un cliente a otro no implica volver a aprender dónde vive cada cosa.
Menos tiempo entre pedir un módulo y tenerlo probado
La estructura completa —capas, rutas, permisos, pruebas— sale generada de una vez, no se escribe pieza por pieza a mano.
Menor riesgo en el momento del despliegue
El diagnóstico previo y el contrato de pruebas detectan lo que antes se descubría en producción — con su corrección, no solo la alarma.
Crecer a varios clientes no obliga a rehacer el proyecto
El modo multiempresa se decide una vez, al instalar. Un proyecto que empieza con un solo cliente puede sumar más sin reescribir su base.
La calidad no depende de quién esté de turno
El patrón lo aplica el generador, no la memoria de la persona que escribe el código ese día.
Un cambio al patrón llega a todos los proyectos por igual
Mejorar el generador una vez mejora la próxima entrega en cualquier proyecto que lo use — sin tener que corregir cliente por cliente.
Ventajas para el equipo de TI
Lo que cambia en el trabajo del día a día
La arquitectura en capas no es una recomendación, es lo que se genera
Controlador, servicio, repositorio y modelo separados desde el primer momento — no un objetivo que se persigue a mitad del proyecto.
El mismo criterio de pruebas en todos los módulos
El contrato de pruebas cubre siempre los mismos temas, en el mismo orden, corta en el primer nivel que falla y corre sobre una base clonada, nunca la real.
Los errores traen la corrección, no solo el aviso
El diagnóstico del proyecto (innodite:doctor) señala qué está mal y qué comando o archivo corregirlo — antes de que el fallo aparezca en el despliegue.
Migraciones organizadas, sin duplicados entre contextos
Cada migración vive junto a la subfuncionalidad a la que pertenece, y el propio generador detecta si una tabla se declaró dos veces.
Personalizar el código generado es una decisión, no un accidente
Las plantillas del generador se exportan solo cuando el equipo decide tocarlas — no quedan copias congeladas desde el día de la instalación.
Multiempresa sin lógica repetida por cliente
Un único código de contexto (central o del cliente activo) resuelve la conexión de base de datos; ningún módulo necesita saber cuántos clientes hay.
Se adapta al proyecto, no al revés
Dos modos, elegidos una sola vez
Ningún comando adivina el modo del proyecto ni asume uno por defecto: se elige al instalar, y desde ahí el generador escribe en consecuencia.
Aplicación única
Un solo cliente, una sola base de datos. El generador escribe la estructura sin ningún eje de contexto adicional — la forma más simple, para el proyecto que no necesita más.
Multiempresa
Varios clientes sobre el mismo código. El generador separa lo central de lo particular de cada cliente y despliega uno, varios o todos con el mismo comando.
En una mirada
Lo que el paquete ya demuestra hoy
La estructura ya no depende de quién la escriba
El manual técnico tiene el detalle de cada comando, con sus parámetros y lo que genera. Esta página es el resumen para decidir adoptarlo o para explicárselo a quien todavía no lo usa.