Fronteras, cohesión y dirección de las dependencias
Separa responsabilidades según los cambios y los contratos, y luego decide qué fronteras necesitan una red.
AL TERMINAR, PODRÁS
- Identificar responsabilidades cohesivas y acoplamiento
- Separar módulos lógicos de unidades de despliegue
- Comparar un monolito modular con servicios desplegados de forma independiente
Descripción del diagrama: Controlador HTTP → Política de la cola (llama); Política de la cola → Puerto de almacenamiento (usa); Adaptador SQLite → Puerto de almacenamiento (implementa)
Empieza por lo que cambia junto
Relay tiene política de envío, política de planificación, ejecución y reporte de resultados.
Si introducir un tipo de trabajo exige ediciones en todas partes, quizá las fronteras estén jugando en tu contra. Agrupa el comportamiento alrededor de una responsabilidad clara y expón un contrato pequeño. Oculta los detalles de los que no deberían depender quienes usan el módulo, como el esquema de almacenamiento o la representación de los reintentos.
Las buenas fronteras se descubren examinando escenarios de cambio y responsabilidades, no haciendo que todos los archivos tengan el mismo tamaño. Un módulo pequeño y cohesivo igual puede contener varias funciones y tipos.
Mantén la política independiente de los detalles reemplazables
El planificador puede depender de una interfaz de cola en lugar de llamar a un driver de base de datos por todo su código de política.
Un adaptador de almacenamiento implementa esa interfaz. Las pruebas (tests) pueden proporcionar un adaptador controlado y ejercitar la planificación sin red. Esto es inversión de dependencias (dependency inversion): la política de alto nivel define lo que necesita y los detalles técnicos se ajustan.
Las interfaces tienen un costo, así que introdúcelas en costuras con sentido. No crees una abstracción para cada línea. Una buena pregunta es si un cambio probable se vuelve local y si el comportamiento ante fallas sigue siendo visible.
Una frontera de red cambia el contrato
La separación lógica no exige servicios separados.
Un monolito modular puede mantener interfaces claras mientras comparte despliegue y transacciones. Los servicios desplegados de forma independiente pueden servir a equipos separados o a un escalado aislado, pero las llamadas pueden agotar su tiempo después de que el trabajo ocurrió, los esquemas evolucionan de forma asíncrona y las transacciones entre servicios necesitan coordinación. Evalúa la capacidad operativa del equipo y la frontera del dominio antes de extraer un servicio.
En Relay, separar los workers de larga duración de la API puede ser valioso aunque ambos vengan del mismo repositorio y compartan un modelo de datos gestionado con cuidado.
ERROR FRECUENTE
Decir que un sistema tiene bajo acoplamiento porque sus partes usan HTTP. Las tablas compartidas, los lanzamientos sincronizados y las cadenas de peticiones muy conversadoras pueden crear un acoplamiento fuerte a través de la red.
INTÉNTALO TÚ
Enumera los cambios necesarios para reemplazar el adaptador de almacenamiento de Relay. Luego enumera qué cambia cuando se agrega un tipo de trabajo. Usa esos dos escenarios para criticar tus fronteras de módulos.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Dibuja los módulos lógicos de Relay. Para cada frontera, escribe el contrato, el responsable, las dependencias y qué cambio pretende aislar.