Preguntas diferentes#
API-DD no reemplaza estos enfoques. Pueden combinarse cuando cada uno conserva su pregunta principal.
| Enfoque | Pregunta que ayuda a responder | |---|---| | DDD | ¿Qué significa el modelo y dentro de qué contexto? | | Arquitectura hexagonal | ¿Qué conversaciones conectan la aplicación con actores y tecnologías? | | TDD | ¿Cómo hacemos crecer el comportamiento mediante feedback ejecutable? | | API-DD | ¿Cómo se comunican los módulos y qué contrato ofrece cada uno? |
No hace falta adoptar los cuatro. La tabla sirve para evitar que una técnica responda preguntas que no le corresponden.
DDD aporta significado#
DDD ayuda a descubrir conceptos, invariantes, lenguaje y límites de modelo. Cuando dos áreas utilizan una palabra parecida, permite decidir si comparten significado o necesitan representaciones distintas.
API-DD puede aprovechar ese resultado para diseñar las conversaciones que los consumidores necesitan. No decide por sí solo cuál es el modelo correcto ni requiere que el trabajo empiece por DDD.
La referencia utilizada aquí es DDD Reference de Eric Evans.
La arquitectura hexagonal orienta conversaciones#
Un port representa una conversación con propósito; los adaptadores conectan mecanismos concretos a ella. Desde API-DD, ese port puede mirarse como una API: mensajes, vocabulario, garantías y efectos.
No todo módulo necesita convertirse en un port. Dos módulos internos pueden colaborar mediante una API local sin representar un límite arquitectónico de la aplicación. Convertir cada relación en port añadiría visibilidad y sustitución sin una necesidad real.
La intención original de puertos y adaptadores está descrita por Alistair Cockburn en Hexagonal Architecture.
TDD guía la construcción#
TDD aporta el ciclo de feedback: elegir el siguiente comportamiento, escribir un test que falle, implementarlo y refactorizar. API-DD ayuda a formular ese comportamiento como una garantía observable de un módulo.
garantía del contrato → rojo → verde → refactorEl test puede descubrir que el contrato estaba incompleto. En ese caso se revisa la decisión antes de continuar; no se fuerza la implementación para conservar una especificación equivocada.
El ciclo se apoya en la descripción de TDD de Martin Fowler, basada en el trabajo de Kent Beck.
Ejemplo en Go#
Supongamos que un módulo necesita guardar y recuperar bytes por clave. Esta API puede actuar como port de salida cuando existen proveedores intercambiables.
type Key string
type Value []byte
type Store interface {
Load(Key) (Value, bool, error)
Save(Key, Value) error
}La arquitectura hexagonal orienta esta dependencia hacia la necesidad del consumidor. API-DD ayuda a hacer visibles decisiones como qué significa ausencia, quién posee los bytes devueltos y qué errores deben distinguirse. TDD permite implementar esas garantías una a una. Si nunca habrá otro proveedor ni un límite relevante, una interfaz separada puede ser innecesaria.
Confusiones frecuentes#
¿Toda API es un port?#
No. Todo port ofrece una API, pero una API también puede existir entre módulos internos que no cruzan el límite de la aplicación.
¿Todo módulo necesita una interfaz del lenguaje?#
No. Una API puede expresarse mediante un tipo concreto, funciones, métodos o mensajes. Una interface técnica aporta cuando un consumidor necesita sustitución o desacoplamiento, no como requisito ceremonial.
¿API-DD prescribe un orden de diseño?#
No. Se puede empezar por cualquier módulo, regla o conversación cuyo contrato y riesgo estén claros. API-DD ofrece una perspectiva para revisar cada módulo como una API, sin prescribir una dirección temporal para descubrir el sistema.
¿Un test con varios módulos deja de ser unitario?#
La cantidad de objetos o módulos no determina qué riesgo cubre la prueba. Resulta más útil declarar la API observada y qué implementaciones participan que discutir una etiqueta universal.
¿Observar un mensaje saliente rompe la caja negra?#
No cuando ese mensaje forma parte del efecto prometido. Sí cuando se comprueba una colaboración interna que otra implementación correcta podría resolver de manera distinta.
Una secuencia práctica#
Aclara conceptos y límites con el modelado disponible. Después identifica las conversaciones entre módulos, expresa sus garantías mediante APIs y tests, e implementa en ciclos pequeños sin alterar el contrato.
El trabajo real no será lineal. Un nombre descubierto durante un test puede cambiar el modelo; una restricción arquitectónica puede obligar a revisar la API. La separación de preguntas sirve para entender la decisión, no para imponer fases rígidas.
DDD aclara el significado, la arquitectura orienta las relaciones, TDD guía el cambio y API-DD ayuda a diseñar la conversación.