Cerramos el capítulo de módulos con una cuestión de diseño que distingue a un buen ingeniero de infraestructura: ¿debo hacer mis módulos muy genéricos (que sirvan para todo) o específicos de mi dominio (que resuelvan exactamente mi caso)? No hay una respuesta única, pero entender el equilibrio te ayudará a diseñar módulos que de verdad faciliten el trabajo, en lugar de complicarlo.

Cuando creas un módulo, te enfrentas a una decisión sobre cuánta flexibilidad ofrecer:

Un módulo genérico intenta servir para muchos casos distintos. Expone muchas variables de entrada para que quien lo use pueda configurarlo todo. Es flexible y muy reutilizable.

Ventaja: sirve para casi cualquier situación. Inconveniente: es complejo de usar, porque quien lo llama tiene que entender y rellenar muchas opciones, y puede equivocarse.

Un módulo específico de dominio resuelve un caso concreto de tu organización, con decisiones ya tomadas. Expone pocas variables porque la mayoría de cosas vienen fijadas según las convenciones de tu empresa.

Ventaja: facilísimo de usar, y aplica automáticamente las buenas prácticas de tu empresa. Inconveniente: solo sirve para ese caso concreto; no es reutilizable fuera de tu contexto.

Un módulo genérico es como una caja de herramientas profesional completa: tiene de todo y sirve para cualquier trabajo, pero necesitas saber qué herramienta coger y cómo usarla. Un módulo específico de dominio es como un kit listo para una tarea concreta («kit para colgar un cuadro»): solo trae lo justo, con instrucciones simples, y resuelve ese problema sin que tengas que pensar. Para colgar un cuadro, el kit es más cómodo; para trabajos variados, necesitas la caja completa.

Un error muy común de los principiantes es intentar hacer todo súper genérico «por si acaso». El resultado es un módulo con decenas de variables que es tan complicado de usar como escribir los recursos a mano. Has añadido complejidad sin aportar valor.

Regla de oro: un módulo debe esconder complejidad, no añadirla. Si usar tu módulo es tan difícil como no usarlo, algo va mal en el diseño.

El extremo contrario también tiene su riesgo: si haces módulos tan específicos que cada uno sirve para un solo proyecto, acabas con muchísimos módulos casi idénticos y poca reutilización real. Pierdes parte del beneficio de los módulos.

La clave está en el equilibrio, y una buena estrategia es la de las dos capas:

• Los módulos genéricos (a menudo del Registry, subcapítulo 18.3, o módulos base propios) aportan la flexibilidad y la lógica reutilizable.
• Los módulos específicos de dominio los envuelven, fijando las decisiones de tu empresa (seguridad, nombres, regiones...) y exponiendo solo lo justo. Son los que usan los equipos.

Ejemplo del mundo real: el equipo de plataforma de una empresa usa el módulo de VPC genérico del Registry (que tiene 40 opciones). Pero no obliga a cada equipo a lidiar con esas 40 opciones. En su lugar, crea un módulo específico red-empresa que internamente llama al genérico con todas las decisiones corporativas ya tomadas (rangos, etiquetas, seguridad), y solo pide al usuario un nombre y un entorno. Los equipos obtienen una red perfecta pasando dos valores, y la flexibilidad del módulo genérico sigue ahí por debajo cuando hace falta.

Cuando crees un módulo, pregúntate:

• ¿Quién lo va a usar? Si son muchos equipos no expertos → tira a específico y fácil. Si es para el equipo de plataforma → puede ser más genérico.
• ¿Cuántas veces y en cuántos contextos se usará? Muy reutilizado en contextos variados → más genérico. Para un caso concreto de tu empresa → específico.
• ¿Estoy escondiendo complejidad o añadiéndola? Si añades complejidad, replantéatelo.
• ¿Cada variable que expongo es realmente necesaria? En la duda, menos variables: empieza simple y añade flexibilidad solo cuando se demuestre necesaria.

• Al diseñar un módulo, eliges cuánta flexibilidad ofrecer: genérico (muchas variables, sirve para mucho, pero complejo de usar) o específico de dominio (pocas variables, fácil, pero solo para tu caso).
• Como herramientas: el genérico es la caja completa (versátil pero requiere saber); el específico es el kit para una tarea (cómodo y directo).
• Error común: pasarse de genérico «por si acaso» y crear un módulo tan complicado que no simplifica nada. Un módulo debe esconder complejidad, no añadirla.
• Mejor estrategia: dos capas. Módulos genéricos (base/Registry) que aportan flexibilidad, envueltos por módulos específicos de dominio que fijan las convenciones de la empresa y son fáciles de usar.
• En la duda, empieza simple (pocas variables) y añade flexibilidad solo cuando se demuestre necesaria.

¡Has terminado el Capítulo 18! Ya sabes diseñar, versionar y componer módulos como un profesional. En el Capítulo 19 veremos cómo gestionar múltiples entornos (desarrollo, staging, producción) con Terraform: workspaces, estrategias de directorios y Terragrunt.