Data 360 Data Architecture: Style Guide | Cleon

Esta es la página donde Cleon deja de describir qué es el modelo de Data 360 (antes Data Cloud) y empieza a decir qué hacemos con él. Salesforce define lo que es posible. Las páginas de referencia de esta subcategoría documentan cada superficie — DLOs, DMOs, data spaces, relaciones y keys. Los gotchas documentan las decisiones que componen. Este Style Guide es la disciplina que mantiene confiable a un modelo de Data 360 un año después del build — y, porque el modelo es lo que un agente lee, la disciplina que vuelve seguro fundamentar Agentforce o un LLM externo sobre él.

Usalo como checklist antes de que cualquier cambio de modelo se publique: un DMO nuevo, un mapping nuevo, un data space nuevo, una relación, una key. Las reglas son cortas a propósito — cuando una regla necesita explicación, la explicación está en la página que linkea.

Naming

Los DLOs y DMOs siguen una convención escrita, decidida antes de que exista el primer objeto

Una convención de naming para objetos y atributos, escrita y hecha cumplir en review, antes de que aterrice el primer DLO. La deriva en naming es la misma deuda compuesta que cincuenta Data Extensions sin prefijo en Marketing Cloud. (Ver gotchas — gotcha 9.)

Los DMOs custom se nombran por significado, no por origen

El nombre de un DMO custom refleja lo que significa en el negocio (LoyaltyAccount), no el sistema del que vino (SAP_ZTABLE_07). El nombre es la documentación que el próximo modelador lee primero.

Los data spaces se nombran por el límite que hacen cumplir

Según data spaces. El nombre codifica el límite — marca, región, régimen regulatorio — para que la razón de la partición sea visible sin preguntar.

Disciplina de modelado

Diseñá el modelo en papel antes de conectar el primer stream

Según gotchas — gotcha 1. Objetos, grano, keys, relaciones, dibujados antes de la ingesta. El modelo es la decisión que heredan todas las demás superficies.

Mantené el DLO crudo y el DMO con significado

Según gotchas — gotcha 2, y mapping. Armonizá en el camino del DLO al DMO; nunca mapees uno-a-uno y lo llames modelar.

Mapeá a un DMO estándar salvo que puedas nombrar qué falta

Según DMOs y gotchas — gotcha 4. Los objetos estándar cargan semántica que la resolución de identidad, la segmentación y los agentes ya entienden. Custom es propiedad que tomás deliberadamente.

Elegí una primary key estable, en la creación

Según relaciones y keys y gotchas — gotcha 3. Lo que identifica de forma única y estable a una fila durante su vida — la disciplina de SubscriberKey, una capa más arriba.

Modelá las relaciones que los consumidores van a necesitar, antes que los consumidores

Según relaciones y keys y gotchas — gotcha 6. Una relación no modelada es un traversal que la segmentación silenciosamente no puede hacer.

Particioná los data spaces por un límite real, no por conveniencia

Según data spaces y gotchas — gotcha 5. Un data space es una pared que construís una sola vez. Default a un solo espacio.

Disciplina de documentación

Documentá el modelo como una API

Según gotchas — gotcha 12. Cada DMO carga una línea: qué contiene, su key, su origen, su frescura. Un modelo sin esa doc es una situación de rehén.

Modelá el consentimiento y el propósito de uso junto a la data

Según gotchas — gotcha 8. Data 360 es el punto de enforcement. Un segmento no debe poder activar a una persona en un canal del que se dio de baja.

Dejá por escrito la frescura de cada stream

Un consumidor necesita saber si un campo es real-time o de hace un día. La cadencia vive en la doc del modelo, no en la memoria de alguien.

Patrones a preferir

DMO estándar sobre custom, cada vez que podés nombrar el objeto estándar que encaja.
Un solo data space hasta que un límite genuinamente demande un segundo.
Calculated Insights para métricas compartidas — computá una vez, recuperá muchas (sobre todo para agentes).
Normalizá en la capa de mapping, para que cada consumidor downstream lea el mismo valor limpio.
Un review del modelo por alguien que ya corrió un build de Data 360, con autoridad de frenar un go-live.

Patrones a rechazar

Lógica de negocio contra DLOs. Construí sobre DMOs. (Según DLOs.)
Un DMO custom que no podés justificar contra el modelo estándar.
Un data space creado por conveniencia organizacional.
Un mapping publicado sin un review campo por campo contra el significado real del origen.
PII ingerida antes de modelar el consentimiento.
"Lo documentamos después". La documentación del día uno cuesta horas; la de seis meses cuesta días.

El chequeo de agent-readiness

El trabajo moderno de Data 360 es ser la data sobre la que un agente — Agentforce o un LLM externo — puede fundamentarse. "Agent-ready" no es una feature que activás; es el estado en el que ya estás si el modelo está bien construido. Antes de apuntarle cualquier agente al perfil unificado, confirmá:

[ ] Un analista humano puede sacar una respuesta coherente y completa sobre un cliente del perfil unificado.
[ ] La resolución de identidad unifica los registros correctos — ningún par de clientes fusionado, ningún cliente partido.
[ ] Las relaciones que implican las preguntas de un agente están modeladas (persona a órdenes a ítems).
[ ] Las métricas compartidas existen como Calculated Insights que el agente recupera, no valores que recomputa.
[ ] Cada DMO está documentado — significado, key, origen, frescura.
[ ] El consentimiento y el propósito de uso están hechos cumplir en el modelo, para que un agente no pueda actuar más allá de ellos.

Si alguna casilla queda sin tildar, el modelo no está agent-ready — y un agente fundamentado sobre él se va a equivocar con seguridad. El trabajo de arriba es el mismo que vuelve productivo a un analista humano; el agente es apenas el lector más exigente.

El chequeo de disciplina antes de que cualquier cambio de modelo se publique

[ ] El cambio está documentado — significado, key, origen, frescura, rationale, dueño.
[ ] El naming sigue la convención del tipo de objeto.
[ ] DMO nuevo: mapeado a estándar, o una justificación nombrada para custom.
[ ] Key nueva o cambiada: estable durante la vida del registro; seteada en la creación, no retrofiteada.
[ ] Relación nueva: la cardinalidad coincide con la realidad y está documentada.
[ ] Data space nuevo: el límite es real y la audiencia es disjunta.
[ ] Mapping revisado campo por campo contra el significado real del origen.
[ ] Consentimiento y propósito de uso modelados para cualquier PII nueva.
[ ] El chequeo de agent-readiness de arriba sigue pasando después del cambio.

Cuando todas tildan, el cambio de modelo está listo para publicar.

Relacionado

Principios de Data 360 desde producción — las meta-reglas por encima de estos específicos
Gotchas de arquitectura de Data 360 — las decisiones que este Style Guide está diseñado para evitar que compongan
Data Lake Objects (DLOs) — la capa de aterrizaje crudo
Data Model Objects (DMOs) — la capa armonizada
Mapear DLOs a DMOs — cómo se asigna el significado
Data spaces — el límite dentro del que vive el modelo
Relaciones y keys — cómo conectan y deduplican los objetos
Debuggear fallas de mapping — cuando un valor aterriza mal o en blanco

Si encontrás una regla que falta — o una de estas reglas violada en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o la arreglamos y lo decimos.