En esta página
Propiedad de arquitectura
COADF P-7 se publica íntegro. Los sistemas de clasificación, las bases de datos terminológicas y los servicios de validación externos viven en módulos adaptadores, marcados como tales, fuera del modelo de datos del núcleo. Un servicio externo puede elevar la confianza de un atributo; ninguno puede bloquear una salida. Cuando un servicio no está disponible, el sistema produce evidencia con menos confianza en lugar de nada; cuando cambia una licencia, el núcleo no se toca; y el contenido con licencia se marca en sus metadatos y se mantiene separado del núcleo abierto.
Cómo cambia la confianza una respuesta externa no lo publica COADF y no se describe aquí. Los ejemplos registran una respuesta externa y su estado, y no hacen nada más con ella.
Por qué importa
Las normas y los vocabularios sobreviven a los productos, cambian de versión según su propio calendario, llevan condiciones de licencia y los sirven sistemas que no opera uno mismo. Cada una de esas cosas es una vía para que la decisión de otro se convierta en una caída o una reescritura propias. El mapa regulatorio de COADF nombra ECLASS y el IEC Common Data Dictionary como vocabularios con licencia tratados de este modo; el mismo razonamiento vale para un resolvedor de identificadores, un proveedor de clasificaciones o un servicio de validación externo con su propia disponibilidad.
El dominio necesita sus respuestas. No debe necesitarlas para funcionar, y no debe empezar a pensar en sus términos.
Estrategias de implementación válidas
- Puerto y adaptador. El dominio define la interfaz que necesita, con sus propias palabras; cada sistema externo recibe un adaptador que la implementa.
- Capa anticorrupción. El adaptador traduce el modelo externo al modelo del dominio y de vuelta, de modo que los conceptos y nombres externos se detienen en el borde.
- Identificadores propios. El dominio conserva su propia identidad para un concepto, y almacena un código externo como referencia atribuida: el esquema, la versión del esquema, el código, de dónde vino, cuándo y si tiene licencia.
- Fijar la versión. Un código significa algo solo dentro de una versión de su esquema. Se registra la versión con cada referencia almacenada y se envía con cada consulta. Un transporte nuevo o una representación nueva del proveedor pueden quedarse dentro del adaptador; una versión semántica nueva de la norma puede cambiar lo que significan los códigos, y entonces la correspondencia del dominio tiene que cambiar con ella.
- Ausencia explícita. Un servicio no disponible produce un “no disponible” registrado, nunca un valor por defecto y nunca una pipeline detenida. Cada llamada tiene un tiempo de espera, y el camino crítico no espera un enriquecimiento del que puede prescindir.
- Marcar el contenido con licencia. Cada valor almacenado que procede de una fuente con licencia lleva una marca, para que las exportaciones, los logs, las cachés y los artefactos públicos puedan dejarlo fuera de forma mecánica.
- Una frontera de plugins donde los adaptadores son opcionales o los aportan terceros: cargados mediante un registro del que el dominio no depende.
En Python el puerto puede ser un typing.Protocol, que comprueban los comprobadores de tipos estáticos; una comprobación isinstance en tiempo de ejecución contra él necesita @runtime_checkable y verifica solo que los métodos existen, no sus firmas. Lo que verifica el comportamiento es la prueba de contrato.
Modos de fallo
Todo fallo llamado caída
Un tiempo de espera agotado, una credencial revocada, una petición mal formada y una respuesta con una forma nueva, todos informados como “no disponible”. La caída se cura sola; la integración rota se reintenta para siempre y nunca se arregla. Hay que mantener separados al menos lo no encontrado, la indisponibilidad transitoria y una integración rechazada, en los términos del propio adaptador, no en los códigos de estado del proveedor.
Las clases externas se filtran por el dominio
Los tipos del proveedor aparecen en las firmas del dominio, después en el esquema de la base de datos y después en la API pública.
El SDK del proveedor se convierte en el modelo del dominio
Las clases generadas se usan como entidades porque ya estaban ahí, y el modelo del proveedor pasa a ser el propio sin que nadie lo diga.
Un cambio de licencia o de API obliga a reescribir lógica del dominio
Cambian las condiciones, el proveedor retira una versión o aparece un proveedor mejor, y el cambio toca todos los módulos en lugar de un adaptador.
Una caída remota bloquea procesamiento no relacionado
Una llamada síncrona sin tiempo de espera está en el camino crítico, y un incidente del proveedor se convierte en un incidente propio.
Los identificadores externos adquieren un significado interno accidental
Las reglas de negocio se bifurcan según un código externo; la siguiente versión del esquema reutiliza o divide el código, y una regla que nadie tocó cambia de comportamiento.
El contenido con licencia se escapa
A los fixtures, los logs, los mensajes de error, las cachés, la documentación pública o el texto enviado a un modelo.
Las pruebas dependen del servicio en vivo
La suite pasa solo cuando el proveedor está disponible, así que la disponibilidad del proveedor se convierte en la disponibilidad de la propia compilación.
Verificación
Prueba unitaria
Pasa cuando: El dominio funciona contra un doble de prueba del puerto.
Prueba de dientes: Se sustituye el doble por uno que lanza el error “no disponible” del adaptador: el dominio sigue produciendo su registro, marcado como no enriquecido.
Prueba de arquitectura
Pasa cuando: Los paquetes del dominio no importan ningún paquete del proveedor ni ningún módulo adaptador.
Prueba de dientes: Se planta la importación del proveedor en un módulo del dominio: la regla falla.
Prueba de contrato
Pasa cuando: El adaptador real y el doble de prueba superan las mismas pruebas de contrato del puerto.
Prueba de integración
Pasa cuando: Los tiempos de espera agotados y los errores de conexión del cliente real se convierten en el error propio del dominio, y nunca en una excepción genérica que detiene la pipeline.
Prueba de integración
Pasa cuando: Una representación nueva del proveedor cambia solo el adaptador, y deja intactas la API y las pruebas del dominio. Una versión nueva del esquema cambia los datos de correspondencia, y las pruebas que fijan las reglas del dominio dicen si alguna regla dependía de un código que se movió.
Evidencia manual
Pasa cuando: Una revisión de licencias de cada adaptador: qué puede almacenarse, durante cuánto tiempo y dónde puede aparecer.
Realizaciones alternativas
- Un lenguaje publicado o modelo canónico compartido por varios contextos delimitados, con cada esquema externo trasladado a él una sola vez.
- Un servicio envoltorio alrededor de un proveedor, para que cada consumidor encuentre la misma interfaz estable.
- Una copia espejo de un vocabulario, donde la licencia lo permita, para que las consultas dejen de depender de la disponibilidad.
- Código generado en la compilación a partir de un esquema, mantenido dentro del paquete del adaptador y nunca exportado desde él.
Limitaciones
- El aislamiento no resuelve las condiciones de licencia. Hace que puedan aplicarse en un solo lugar.
- La correspondencia pierde matices. Una tabla de correspondencias es conocimiento del dominio y necesita su propia revisión.
- El patrón no describe cómo afecta la evidencia externa a la confianza, lo que corresponde a P-2.
Fuentes
- Python Software Foundation: typing.Protocol and runtime_checkable · documentación del lenguaje · Python 3.14 · Comprobado el 2026-09-11