Software Architecture
Explica cómo definir límites, contratos y ownership de capacidades, datos, decisiones y operación para evitar responsabilidades compartidas y dependencias ocultas.
Un límite arquitectónico define qué responsabilidad, datos y decisiones pertenecen a una parte; un contrato define cómo pueden colaborar otras partes sin depender de sus internals; el ownership determina quién responde por su corrección y evolución.
Los límites reducen el conocimiento compartido. Pueden existir entre clases, módulos, procesos, dominios, equipos o sistemas externos.
Un límite sano responde:
consumidor
→ contrato público
→ límite
→ modelo, datos y mecanismos internosSin ownership y contratos claros:
Un límite no es aislamiento absoluto. Permite colaboración controlada y hace explícitos los costos de esa colaboración.
Un contrato es la promesa observable del proveedor. Incluye más que una firma o schema:
Operaciones, campos, tipos, formatos y unidades.
Qué significa cada operación y estado.
Qué fallos pueden ocurrir, cuáles son reintentables y cómo se representan.
Sincronía, timeouts, orden, duplicados y consistencia.
Identidad, autorización, alcance y auditoría.
Qué cambios son seguros, política de versión y deprecación.
Rate limits, disponibilidad, observabilidad y soporte.
Dos sistemas pueden usar el mismo JSON y seguir teniendo contratos incompatibles si uno interpreta confirmed como pago autorizado y otro como dinero capturado.
Ownership significa autoridad y responsabilidad, no solo “quién creó el código”.
Incluye:
Ejemplo:
Orders
→ posee estados del pedido y su ciclo de vida
Inventory
→ posee disponibilidad, reservas y movimientos
Payments
→ posee intentos, autorizaciones y conciliaciónOrders puede solicitar una reserva, pero no debería reducir directamente una columna de Inventario.
Cada dato necesita una fuente de verdad.
order.status
→ autoridad: Orders
inventory.available
→ autoridad: Inventory
payment.authorizationId
→ autoridad: PaymentsOtros módulos pueden conservar copias derivadas, pero deben saber:
Compartir lectura puede ser aceptable. Compartir escritura suele repartir invariantes y vuelve insegura la evolución.
Pueden evolucionar con coordinación más cercana, pero siguen necesitando semántica y ownership. “Interno” no significa que todos puedan romperlo.
Tienen consumidores fuera del control directo. Necesitan política de compatibilidad, deprecación, autenticación y soporte más estricta.
La diferencia no siempre es técnica. Una API entre equipos autónomos puede requerir disciplina similar a una API pública.
Contrato demasiado técnico:
interface InventoryRepository {
updateAvailable(productId: string, delta: number): Promise<number>;
}Permite cualquier delta y obliga al consumidor a conocer representación.
Contrato orientado a capacidad:
interface InventoryModule {
reserve(input: ReserveStock): Promise<ReservationResult>;
release(input: ReleaseReservation): Promise<ReleaseResult>;
}La frontera protege reglas, tenant, concurrencia e idempotencia.
1. Orders recibe ConfirmOrder.
2. Verifica identidad, tenant y estado.
3. Solicita una reserva a Inventory.
4. Inventory valida disponibilidad y crea reservationId.
5. Orders registra la confirmación usando esa referencia.
6. Publica OrderConfirmed.
7. Otros consumidores reaccionan sin escribir internals de Orders.Si los módulos son procesos separados, un timeout puede dejar resultado desconocido. El contrato debe incluir idempotencia, consulta de estado o reconciliación. La firma por sí sola no resuelve la incertidumbre.
Cuando un sistema externo utiliza conceptos distintos, una capa anticorrupción traduce su modelo al lenguaje propio.
proveedor:
payment_intent.status = requires_capture
modelo propio:
autorización aprobada, captura pendienteLa traducción evita propagar nombres, unidades y estados externos por todo el dominio.
Una ACL puede incluir:
Una llamada síncrona ofrece respuesta inmediata, pero crea:
Conviene cuando el consumidor no puede continuar sin el resultado y el costo de coordinación es aceptable.
Eventos y mensajes reducen acoplamiento temporal, pero introducen:
No son “menos acoplados” en todos los sentidos. Cambian el tipo de acoplamiento.
Un contrato necesita evidencia.
Comprueban que el proveedor cumple su especificación.
Expresan expectativas reales de consumidores.
Validan transporte, autenticación y serialización.
Comprueban significado: idempotencia, errores, orden y compatibilidad.
Una prueba de schema no detecta que una unidad cambió de centavos a pesos.
Cambios aditivos suelen ser más seguros, pero incluso agregar un valor de enum puede romper consumidores exhaustivos.
Una política debe definir:
Puede mantenerse dentro de un monolito modular si cada tabla tiene propietario y las escrituras cruzadas están prohibidas. La separación física no sustituye ownership.
Un dashboard necesita datos de varios módulos. Usa proyecciones o pipelines; no conviertas reporting en propietario de datos operacionales.
Auditoría o identidad cruza límites. Define capacidades y políticas compartidas sin permitir que un módulo central conozca todas las reglas de negocio.
Romper el contrato puede parecer rápido, pero traslada costo a consumidores. Usa expand-and-contract o versiones cuando la coordinación no es segura.
Una forma de datos sin semántica, errores ni temporalidad es incompleta.
“Todos mantienen esta tabla” normalmente significa que nadie controla invariantes ni evolución.
Tipos ORM, excepciones del proveedor o modelos completos aumentan acoplamiento.
Un evento demasiado amplio o mutable puede convertirse en un modelo global y eliminar autonomía.
Un gateway puede autenticar, pero la autorización sobre recursos debe conservar contexto cerca del propietario.
Clean Architecture organiza estas ideas dentro de una aplicación y muestra cómo proteger políticas de negocio frente a mecanismos externos.