https://patterns.exeal.com/tags/modularidad/Recent content in Modularidad on Patrones — ExealHugoes-ESThu, 24 Sep 2026 00:00:00 +0000https://patterns.exeal.com/patterns/host-fino-y-modulos-deep/Thu, 24 Sep 2026 00:00:00 +0000https://patterns.exeal.com/patterns/host-fino-y-modulos-deep/<h2 id="problema">Problema</h2> <p>A medida que una aplicación crece, es fácil que todo acabe en un único proyecto (o en una pila de proyectos sin fronteras reales) donde cualquier clase puede llamar a cualquier otra. El resultado son dos problemas que se retroalimentan:</p> <ul> <li><strong>No se puede razonar ni testear una pieza en aislamiento.</strong> Para validar la lógica de un caso de uso hace falta levantar medio sistema, porque nada impide que esa lógica dependa de detalles internos de otra parte de la aplicación.</li> <li><strong>Una IA (o una persona nueva) que trabaja sobre una funcionalidad concreta necesita cargar contexto de todo el sistema</strong> para saber qué es seguro tocar y qué no, porque la superficie pública y la implementación interna son indistinguibles a simple vista.</li> </ul> <p>Esto se agrava en aplicaciones con piezas muy distintas entre sí: un listener de webhooks, una API administrativa, lógica de negocio con jobs en background. Cada una tiene su propia complejidad interna, pero todas acaban compartiendo el mismo espacio de nombres sin fronteras que el compilador conozca.</p>