![Imagen de portada de [Modularización #3] Por qué Common se convierte en un cajón de sastre](/assets/images/posts/5485c078-a71f-4122-920c-335272b4db96/1.jpg)
La mayoría de los equipos que modularizan un proyecto termina creando módulos llamados Common, Core o Utils.
Cuando se acumulan decisiones como «se usa en varios sitios, así que déjalo aquí por ahora», el módulo acaba siendo el más grande, el que cambia con más frecuencia y del que todos dependen.
La conclusión: llamar Common a un módulo equivale a admitir que carece de cohesión. «Común» no es un criterio para agrupar código.
Este artículo explica por qué Common revierte la modularización y resume una estructura de capas (separación vertical) y otra de funcionalidades (separación horizontal) para evitarlo.
¿Por qué son peligrosos los módulos Common?
El problema se desarrolla en tres etapas.
Etapa 1: convertirse en un cajón de sastre. Todo «código sin un lugar claro» termina en Common. Junto a un formateador de fechas aparece un cliente de red, y al lado, un botón personalizado. No tienen ninguna relación.
Etapa 2: dependencia universal. Todos los módulos de funcionalidad importan Common. En este punto, Common ocupa la posición más aguas abajo del grafo, que debería ser la más estable.
Etapa 3: recompilarlo todo. Como Common es un cajón de sastre, cambia con más frecuencia. El principio de dependencias estables del artículo anterior queda completamente invertido. Cambias el color de un botón y se recompilan todos los módulos.
Cuando el módulo del que más se depende se convierte también en el que más cambia, los límites entre módulos pierden todo su sentido.
Estructura de capas: dividir verticalmente
El primer eje preventivo es la separación vertical por responsabilidad. Una estructura habitual de 3 o 4 capas es la siguiente.
| Capa | Contenido | Ejemplo |
|---|---|---|
| Feature | Módulos de pantalla/funcionalidad | Inicio, búsqueda, pedidos, ajustes |
| Domain | Reglas de negocio, modelos y casos de uso | Políticas de pedidos, modelos de miembros |
| Core | Wrappers ligeros de tecnologías concretas | Red, almacenamiento, registro |
| Shared | Utilidades realmente genéricas | Formateadores de fechas, extensiones de String |
Solo hay una regla: las dependencias fluyen de arriba abajo.
Feature puede usar Domain y Core, pero Core no debe conocer Feature. Las Feature tampoco se referencian directamente; el target superior de la app las ensambla.
Aquí importa la diferencia con Common. Core no es un módulo gigante, sino varios módulos divididos por tecnología.
- Por ejemplo, CoreNetwork, CoreStorage y CoreLogging son módulos independientes.
- Si la funcionalidad de búsqueda solo usa registro, importa únicamente CoreLogging.
Así, corregir el código de red no recompila el módulo que solo usaba registro.
Estructura de funcionalidades: dividir horizontalmente
El segundo eje es la separación horizontal por dominio. Incluso dentro de la misma capa, Inicio, Búsqueda y Pedidos deben ser módulos distintos.
El criterio es la pregunta del primer artículo: «¿Este código cambia por el mismo motivo?»
- Si cambiar la política de búsqueda no obliga a cambiar el código de pedidos, son módulos distintos.
- Si la pantalla de pedidos y el caso de uso de pedidos siempre cambian juntos, dividirlos más verticalmente puede ser excesivo.
Al superponer la división vertical (capas) y horizontal (funcionalidades), se obtiene una cuadrícula. Cada módulo real ocupa una celda, como «Domain de pedidos» o «Feature de búsqueda».
¿Y si Common ya ha crecido demasiado?
No hace falta eliminar el Common existente de una vez. El orden validado en la práctica es el siguiente.
- Prohibir nuevas incorporaciones: establece primero la regla de no añadir código nuevo a Common desde hoy.
- Investigar usos: empezando por el código que cambia con más frecuencia, comprueba dónde se utiliza realmente.
- Encontrar su lugar: si solo lo usa una funcionalidad, muévelo a su módulo; si es un wrapper tecnológico, muévelo a un módulo de la familia Core.
- Renombrar lo restante: aísla solo el código realmente genérico que quede bajo un nombre más preciso, como Shared.
Es un trabajo de meses, pero en cada etapa puedes comprobar que el alcance de recompilación se reduce de forma visible.
¿Cuándo hace falta esta estructura y cuándo es excesiva?
- Con 4 o 5 desarrolladores o más y al menos 3 áreas funcionales: merece la pena establecer reglas de capas.
- En un proyecto de 1 o 2 personas: basta con empezar con dos capas, Feature/Shared. Dibujar la cuadrícula completa sería excesivo.
- A cualquier escala: recomendamos respetar desde el principio la regla de «no crear módulos llamados Common o Utils».
Así lo planteo en una entrevista
Q. ¿Qué problemas aparecen cuando crece un módulo común (Common) y cómo conviene diseñarlo?
El módulo del que todos dependen se convierte en el que más cambia, por lo que incluso una modificación pequeña exige recompilar todo y revisar un impacto amplio. El principio de dependencias estables queda invertido. Divídelo por responsabilidades —red, almacenamiento y registro— y aísla solo el código realmente genérico en un módulo Shared mínimo.
Q. Explica las reglas para dividir una estructura de módulos en capas.
Define capas por responsabilidad, como Feature, Domain y Core, y permite dependencias en una sola dirección: de arriba abajo. Los módulos de una misma capa no deben referenciarse directamente; conéctalos en la capa de ensamblaje superior. Así, el impacto de los cambios queda limitado a las capas superiores.
Hasta aquí llega la trilogía de principios de la modularización. Con límites, dirección de dependencias y estructura de capas, ya tienes las herramientas conceptuales necesarias.
A partir del próximo artículo aplicaremos estos principios directamente a proyectos iOS, empezando por cómo dividir módulos con Swift Package.