Componentes, responsabilidades y acoplamiento
¿Por qué en algunos proyectos cambiar el color o el orden de un formulario en la pantalla termina rompiendo el cálculo de las facturas o el guardado en la base de datos? Eso ocurre cuando todas las decisiones del sistema están mezcladas en el mismo lugar. Comprender cómo dividir un sistema en componentes con responsabilidades separadas es esencial tanto para razonar sobre él como para encargar modificaciones acotadas a un agente.
Objetivos y conocimientos previos
Partiendo de Pensamiento sistémico, aprenderás qué es un componente lógico, cómo aplicar el principio de separación de responsabilidades, y qué significan cohesión y acoplamiento al evaluar la estructura de un proyecto.
Por qué dividimos un sistema en componentes
Un sistema mediano tiene que resolver problemas de naturaleza muy distinta:
- Mostrar información de forma clara y recoger las acciones de la persona.
- Decidir si una operación cumple las reglas del negocio (aforo, saldos, plazos, permisos).
- Conservar y recuperar registros de forma íntegra.
- Comunicarse con servicios externos (pagos, mensajería, asistentes de IA).
Si un único bloque intenta hacer las cuatro cosas a la vez, cualquier cambio pequeño obliga a leer y arriesgar todo el sistema.
Un componente (o módulo) es una parte delimitada del sistema que agrupa decisiones estrechamente relacionadas y ofrece al resto una forma clara de interactuar con ella sin exponer todos sus detalles internos.
Las tres capas lógicas fundamentales
Independientemente de la tecnología o el estilo arquitectónico, casi todo sistema interactivo distingue al menos tres responsabilidades lógicas:
- Presentación e Interacción (Mostrar estado y recoger intenciones del usuario)
- Lógica de Dominio / Negocio (Evaluar reglas, invariantes y coordinar decisiones)
- Persistencia e Integraciones (Guardar/leer datos y hablar con servicios externos)
| Responsabilidad | Qué debe saber hacer | Qué NO debe decidir |
|---|---|---|
| Presentación (Interfaz) | Mostrar datos al usuario, guiar la entrada y enviar solicitudes al dominio. | No debe ser la única que decide si queda aforo o cuánto cuesta una factura; si mañana añadimos otra pantalla o una app móvil, las reglas se duplicarían o contradirían. |
| Dominio (Reglas del problema) | Aplicar las condiciones del negocio: quién puede reservar, cuándo se libera una plaza, qué transiciones de factura son válidas. | No debe depender de si el botón en pantalla es azul ni de los detalles internos de cómo el disco guarda los archivos. |
| Persistencia e Integración | Ejecutar las lecturas, escrituras transaccionales y llamadas a servicios externos que el dominio solicita. | No debe inventar políticas de negocio por su cuenta (como decidir en silencio qué descuento aplicar a un cliente). |
Cohesión y acoplamiento
Para evaluar si la división de un sistema es sana, usamos dos criterios complementarios:
- Cohesión (qué tan enfocado está cada componente): Un componente tiene alta cohesión cuando todas sus partes colaboran en una misma responsabilidad clara (por ejemplo, el módulo de Reservas gestiona la disponibilidad, creación y cancelación de reservas). Tiene baja cohesión cuando mezcla tareas sin relación (por ejemplo, un archivo que valida reservas, cambia el tema oscuro de la pantalla y formatea facturas en PDF).
- Acoplamiento (cuánto depende un componente de las tripas de otro): Dos componentes tienen bajo acoplamiento cuando se comunican a través de un acuerdo simple y estable, sin necesitar conocer cómo está implementado el otro por dentro. Tienen alto acoplamiento cuando cambiar un detalle interno de uno obliga a reescribir el otro.
Ejemplo claro: Si el módulo de Facturación solo pide al módulo de Notificaciones: «envía el aviso de factura emitida a este cliente con este importe», ambos están desacoplados. Si mañana cambiamos el aviso de correo electrónico a mensaje móvil, Facturación no necesita enterarse ni modificarse.
Cómo te ayuda esta separación al dirigir la codificación con IA
Cuando delegas la codificación en un agente de IA, el diseño modular es tu principal herramienta de control:
- Limita el radio de impacto: Puedes encargar al agente «modifica la pantalla de listado de facturas para filtrar por estado, sin tocar las reglas de emisión ni el esquema de persistencia».
- Facilita la verificación: Si las reglas del negocio están concentradas en el componente de dominio y no esparcidas por diez botones de la interfaz, puedes pedir pruebas directas sobre esas reglas sin depender de simular clics en cada pantalla.
- Permite sustituir tecnologías: Si la lógica de tus reglas está separada del proveedor de correo o de almacenamiento, cambiar de proveedor es una tarea acotada al componente de integración.
Practica
Un agente ha construido una aplicación de reservas con dos pantallas: una Vista Web y un Panel de Administración. Al revisar su explicación, descubres que el agente escribió la regla «verificar que las reservas activas sean menores que 10 antes de insertar en la base de datos» directamente dentro del código del botón de la Vista Web, y volvió a escribir una copia parecida (pero con el número 12 por descuido) dentro del botón del Panel de Administración.
- ¿Qué problema de separación de responsabilidades y duplicación lógica ha cometido el agente?
- ¿Qué ocurrirá cuando desde el Panel de Administración se registren las reservas 11 y 12, o cuando mañana decidas cambiar la capacidad de la actividad a 15 plazas?
- Explica cómo reorganizarías el sistema en componentes para que exista un único lugar responsable de hacer cumplir la regla de capacidad, independientemente de desde qué pantalla se inicie la solicitud.
Criterio de comprensión: debes proponer extraer la regla de negocio a un componente o servicio de dominio común al que llamen tanto la Vista Web como el Panel de Administración, garantizando una única fuente para la regla y evitando que la interfaz escriba directamente en el almacenamiento sin pasar por el dominio.
Profundiza con IA
Esta es mi propuesta para desacoplar las pantallas de la regla de negocio de reservas: [tu respuesta]. Evalúa mi solución y ponme un caso adicional: queremos que un asistente de IA por chat también pueda crear reservas para los usuarios. Pregúntame cómo se conectaría ese asistente a mi arquitectura y qué ventaja tiene haber separado antes el componente de dominio.
Siguiente lectura
Separar la interfaz del servidor de dominio no solo ordena el sistema: también traza una línea divisoria entre lo que controla el usuario en su dispositivo y lo que custodia el sistema. Continúa con Fronteras de confianza, identidad y permisos.