Data Ownership

Autoridad sobre estado autoritativo

Data Ownership examina qué unidad arquitectónica tiene autoridad y responsabilidad para definir, validar y cambiar cada estado autoritativo según sus invariantes y contratos. Estado autoritativo es la representación cuyo significado y cambios esa unidad debe sostener; puede tener varias copias físicas.

Aquí ownership significa autoridad semántica sobre datos. Un equipo puede mantener la unidad, infraestructura puede administrar el servidor y un product owner priorizar trabajo. Esas responsabilidades se relacionan, pero ninguna sustituye automáticamente la autoridad para declarar una autorización válida o modificar stock.

Es una dimensión de architecture-decision-axes, no una tecnología, estilo ni requisito exclusivo de microservices. También importa en monolith, modular-monolith, service-based-architecture y service-oriented-architecture. Nombrar un perfil no demuestra que sus autoridades estén claras.

Significado y responsabilidades en Commerce

Nuestro ejemplo Place Order distribuye responsabilidades entre cuatro capacidades:

Unidad	Estado autoritativo ilustrativo
Orders	Ciclo de vida del pedido.
Payments	Autorización y captura del pago.
Inventory	Stock disponible y reservado.
Shipping	Estado de preparación y envío.

No basta llamar a todas esas representaciones «status». Payments autorizado, Orders confirmado y Shipping despachado expresan hechos distintos. Sus contratos deben aclarar significado y transiciones permitidas. Un valor compartido con semántica ambigua puede ocultar autoridades incompatibles.

La literatura de DDD delimita modelos y hace explícitas sus relaciones; Fowler muestra que términos aparentemente comunes pueden tener sentidos diferentes entre contextos. Eso ayuda a razonar sobre autoridad semántica, sin hacer equivalentes Data Ownership y Bounded Context. Fowler, Bounded Context.

Una decisión de decomposition puede agrupar todas las capacidades o separarlas. En cualquier caso hay que saber qué responsabilidad permite cambiar una reserva, quién valida su cantidad y quién interpreta su vencimiento.

Ownership, almacenamiento, acceso y copia

La ubicación física responde dónde persisten bytes. Ownership responde quién define el significado y los cambios válidos. Una sola base de datos puede contener autoridades lógicas separadas; varias bases pueden permitir escrituras cruzadas que destruyan esa separación.

Leer datos tampoco concede autoridad. Orders puede consultar la dirección de envío de Customer sin controlar el dato maestro del cliente. Si conserva una dirección como snapshot del pedido, debe distinguir ese hecho propio del pedido de una supuesta actualización del registro de Customer.

Una PaymentStatusSummary almacenada en Orders puede apoyar visualización o decisiones permitidas por contrato. Sigue siendo información derivada de Payments. Orders no puede convertir unilateralmente «autorización desconocida» en «capturada» y pretender que el pago real cambió.

Propiedad	Qué permite afirmar
Storage location	Dónde se mantiene una representación.
Read access	Qué información puede consultarse.
Local copy	Qué información se conserva o deriva.
Data Ownership	Quién responde por significado y cambios.

Administrar el schema físico es otra responsabilidad. Un DBA puede ejecutar una migración aprobada sin decidir cuándo debe capturarse un pago. Alinear permisos y schema con autoridad puede facilitar enforcement, pero las funciones no son idénticas.

client-state-management aplica una distinción complementaria al cliente: el browser puede poseer un borrador o administrar una cache sin gobernar el Customer confirmado o el pago real. «Representación canónica local» y «autoridad de negocio» tienen alcances diferentes. Una actualización optimista modifica la expectativa visible; no declara por sí sola un hecho autoritativo del backend.

offline-first puede mantener esa utilidad sin red inmediata mientras conserva pagos o adjudicación de plazas bajo autoridad remota. synchronization relaciona copias e intenciones con decisiones aceptadas; no exige que todos los participantes tengan igual autoridad. Una política de merge puede combinar preferencias y seguir sin poder validar dos reservas sobre la última plaza.

Autoridad lógica con una base compartida

Un modular-monolith puede compartir almacenamiento y conservar tablas de Orders modificables solo mediante el módulo Orders, tablas de Payments mediante Payments e interfaces públicas para consumidores. Su valor está en proteger reglas y representación, no en multiplicar servidores.

Esa frontera necesita hacerse efectiva: accesos restringidos, contratos claros y controles sobre dependencias. Grzybek destaca encapsulación e interfaces explícitas como parte de modularidad, incluso dentro de una unidad de deployment. Compartir proceso no vuelve públicos todos los detalles. Grzybek, Modular Monolith: A Primer.

La base compartida introduce riesgos: escrituras directas entre módulos, joins sobre estructuras privadas, migraciones simultáneas y permisos excesivos. Una convención sin enforcement puede ceder ante la primera urgencia. Pero esos riesgos no prueban que shared DB sea lógicamente incompatible con ownership.

Si Orders actualiza PaymentAuthorization para «simplificar» el flujo, evita las validaciones de Payments. Aunque la escritura sea técnicamente atómica, la arquitectura perdió una autoridad clara. Una corrección exige recuperar el contrato, no necesariamente separar toda la infraestructura.

Database per service: alcance y límites

Private tables, schemas y servidores separados son formas diferentes de proteger datos privados. Richardson aclara que database per service no exige provisionar un servidor por servicio y propone barreras de acceso para sostener la separación. La privacidad lógica es distinta del inventario físico. Richardson, Database per service.

Una base separada puede reforzar enforcement, pero no garantiza buen corte, autoridad semántica ni evolución independiente. Un servicio A que exige constantemente el estado interno de B puede imponer decisiones y conocimiento sobre su representación, aunque no tenga permisos SQL.

Por eso microservice no significa servidor de base de datos propio por definición, y base propia no demuestra ownership correcto. La práctica de datos descentralizados pone énfasis en responsabilidades y modelos por servicio, no en una topología universal de servidores. Lewis y Fowler, Microservices.

Tampoco hay un mandato para copiar toda información remota: consultas, eventos y proyecciones tienen consecuencias diferentes. La elección debe responder a necesidades concretas de latencia, disponibilidad, evolución y significado.

Dependencias y contratos de información

dependency-structure pregunta quién depende de qué. Acceder a tablas privadas depende del schema, representación y ciclo de migración del otro participante. Data Ownership pregunta quién está autorizado a definir y modificar esa información. Los ejes interactúan sin ser intercambiables.

communication decide cómo obtiene Orders información de Payments: contrato de módulo, query, API, evento o proyección local. Ningún canal asigna autoridad por sí solo. Consultar mediante una API que expone todas las tablas internas puede conservar el coupling de schema detrás de otra interfaz.

El contrato debería aclarar qué prueba la respuesta y durante cuánto tiempo sirve para decidir. «Autorizado» puede tener vencimiento; una lectura anterior a una cancelación no es evidencia suficiente para cualquier operación posterior. Autoridad clara no elimina la necesidad de interpretar correctamente información temporal.

Copias, eventos, Outbox e Inbox

Duplicación de datos no exige duplicación de autoridad. Caches, réplicas, read models y analytics pueden favorecer performance, autonomía, disponibilidad o reporting. Cada copia requiere decisiones sobre frescura, sincronización, procedencia, invalidación e inconsistencia aceptable.

En nuestro ejemplo, PaymentAuthorized publica un hecho definido por Payments. Orders puede guardar su identidad y versión para su resumen; recibirlo no transfiere autoridad sobre la autorización original. Si transforma el evento en «pedido elegible para confirmar», ese estado derivado tiene reglas propias de Orders.

transactional-outbox conserva información de integración junto al cambio local para permitir publicación posterior. Su objetivo es relacionar persistencia y publicación, no repartir autoridad. El relay transporta información; no se convierte en responsable semántico del pago por leer la outbox. Richardson, Transactional Outbox.

inbox-pattern puede registrar recepción y deduplicación junto a efectos del consumidor. Ese registro puede ser autoritativo sobre «Orders procesó este mensaje», sin ser autoritativo sobre «Payments capturó dinero». La procedencia debe permanecer reconocible cuando se reconstruye una proyección.

Quién conduce el proceso y quién cambia cada estado

coordination establece cómo Place Order alcanza el resultado conjunto. OrderWorkflow puede dirigir el avance y mantener su propio estado de ejecución. No necesita apropiarse del estado de Payments, Inventory o Shipping.

En el ejemplo, solicita una reserva a Inventory y una autorización a Payments, recoge evidencia y pide confirmar Orders. Si debe compensar, solicita liberar o cancelar mediante contratos. No escribe libremente en tablas ajenas porque sea responsable del progreso.

Una autoridad lógica puede implementarse con varios actores: escritores particionados, réplicas con consenso o modelos colaborativos. Single authoritative writer puede simplificar invariantes, pero no exige universalmente una instancia o thread. Deben quedar explícitos qué cambios son válidos y cómo se resuelven conflictos.

Invariantes y separación física

data-migration distingue copiar, cambiar lecturas, cambiar escrituras y transferir autoridad. Una copia sincronizada puede seguir siendo derivada; cuando el target acepta mutaciones autoritativas, volver al source puede necesitar reconciliación o reparación. Instalar una base gestionada durante cloud-migration tampoco asigna por sí mismo autoridad sobre el pago.

migration-strategy debe explicitar autoridad en cada estado: v1 puede conservar operaciones históricas mientras v2 gobierna una población nueva, con asignación inequívoca por operación. Mover tráfico o instalar v2 no demuestra transferencia de toda la responsabilidad. También importan correcciones tardías, consumidores de copias y obligaciones de retirada.

En strangler-fig o branch-by-abstraction, hacer coexistir caminos no asigna automáticamente autoridad sobre su estado. Precisar quién escribe ahora, quién escribirá después y cuándo cambia esa responsabilidad. parallel-change puede mantener dos representaciones del mismo hecho sin crear dos autoridades; dual writes independientes todavía requieren tratar fallo parcial y reconciliación.

Si Orders empieza a escribir estado privado de Payments contrariando su autoridad acordada, architecture-erosion permite examinar ese debilitamiento. fitness-functions puede evaluar dependencias y permisos efectivos; un check de imports no prueba todas las vías de acceso. Base compartida no implica por sí sola violación de ownership.

Inventory puede proteger localmente stock disponible no negativo bajo un modelo que contabilice reservas y modificaciones concurrentes. Una regla que atraviesa Orders, Payments e Inventory necesita coordinación entre autoridades o reformular qué promete «confirmado». No implica automáticamente consistencia atómica distribuida.

isolation examina qué accesos, efectos y fallos se contienen. Autoridad lógica puede limitar escrituras indebidas y propagación de cambios de schema, sin proteger de una caída del servidor compartido. Separar bases aumenta algunas fronteras y agrega operación, sincronización y coordinación; no es una recomendación universal.

Para evaluar modifiability, cambiar la representación de Payments y observar si Orders conserva su contrato. Para operability, reconstruir la procedencia de un resumen discrepante. Para cost-efficiency, incluir mantenimiento y reconciliación de copias, no solo costo de storage.

Una revisión útil pregunta quién puede declarar cada hecho, quién puede cambiarlo y qué evidencia usa el consumidor. Direcciones de servidor, nombres de equipos y número de copias ayudan a implementar la respuesta, pero no la sustituyen.