9. Atributos del dominio: datos relevantes, derivados y calculados

9.1 Introducción

Los atributos describen características de conceptos del dominio. Una entidad o un objeto de valor puede tener datos que ayudan a identificarlo, explicarlo, validarlo o aplicar reglas. Sin embargo, no todo dato que aparece en un formulario, documento o base de datos pertenece necesariamente al modelo de dominio.

En este tema veremos cómo distinguir atributos relevantes, atributos derivados y atributos calculados. También analizaremos cuándo un dato debe modelarse como atributo, cuándo conviene convertirlo en objeto de valor y cuándo debe quedar fuera del modelo conceptual.

9.2 Tipos de atributos en el dominio

La siguiente imagen resume tres tipos frecuentes de atributos: datos directos que se registran, datos derivados que se obtienen de otros datos y datos calculados que resultan de aplicar reglas o fórmulas del dominio.

9.3 Qué es un atributo del dominio

Un atributo del dominio es una característica relevante de un concepto del negocio. Debe tener significado para el dominio y participar, directa o indirectamente, en la comprensión, comunicación o aplicación de reglas.

Por ejemplo, en un Turno pueden ser atributos relevantes la fecha, la hora, el estado, la duración o el motivo de consulta. En un Paciente pueden ser relevantes el nombre, el documento, el teléfono de contacto o la fecha de nacimiento, siempre que el negocio los necesite.

9.4 Datos relevantes frente a datos accidentales

Un dato relevante ayuda a explicar el negocio. Un dato accidental aparece por razones circunstanciales, técnicas o de interfaz, pero no aporta al modelo de dominio. Por ejemplo, "fecha de nacimiento" puede ser relevante para un Paciente si se usa para validar edad, segmentar atención o identificar personas. En cambio, "color del botón de reserva" no pertenece al dominio de turnos.

También hay datos que pueden ser relevantes en un dominio y no en otro. El color de un producto puede ser central en una tienda de ropa, pero irrelevante en un sistema de turnos médicos. La relevancia depende del contexto.

9.5 Atributos obligatorios y opcionales

Algunos atributos son obligatorios porque el dominio no permite que el concepto exista sin ellos. Otros son opcionales porque pueden desconocerse, completarse después o no aplicar en todos los casos.

Por ejemplo, un Turno puede requerir fecha, hora y profesional para existir. El motivo de consulta podría ser opcional si el paciente puede completarlo más tarde. El correo electrónico de un Paciente puede ser opcional si también se permite contacto telefónico.

La obligatoriedad no debe decidirse solo por comodidad técnica. Debe responder a una regla o necesidad real del negocio.

9.6 Atributos derivados

Un atributo derivado se obtiene a partir de otros datos ya conocidos. Por ejemplo, la edad de una persona puede derivarse de su fecha de nacimiento y la fecha actual. La duración de una franja horaria puede derivarse de hora de inicio y hora de fin.

Los atributos derivados son útiles para comunicación y reglas, pero conviene identificarlos como derivados para evitar inconsistencias. Si guardamos edad y fecha de nacimiento por separado, pueden quedar desalineadas con el paso del tiempo. En cambio, si la edad se calcula cuando se necesita, siempre estará actualizada.

9.7 Atributos calculados

Un atributo calculado surge de aplicar una fórmula o regla del dominio. Por ejemplo, el total de un pedido puede calcularse sumando subtotales, impuestos, descuentos y recargos. El costo de una cancelación fuera de término puede calcularse según una política definida.

La diferencia con un atributo simplemente derivado puede ser sutil. En general, hablamos de cálculo cuando intervienen reglas, fórmulas o decisiones del negocio. Lo importante es que el modelo indique de dónde sale el valor y qué regla lo determina.

9.8 Datos almacenados y datos calculados

En el modelo de dominio podemos distinguir el significado del dato de la decisión técnica de almacenarlo o calcularlo. Un total puede ser calculado conceptualmente, pero el sistema podría almacenarlo por rendimiento, auditoría o requisitos legales. Esa decisión pertenece al diseño técnico.

Durante el análisis, lo importante es saber si el valor es ingresado, derivado o calculado. Luego se decidirá si se guarda físicamente, se recalcula, se cachea o se registra como parte de un historial.

9.9 Atributos que conviene convertir en objetos de valor

Algunos atributos simples crecen en significado y conviene modelarlos como objetos de valor. Esto ocurre cuando un conjunto de datos debe tratarse como una unidad o cuando tiene reglas propias.

Por ejemplo, en lugar de tener monto y moneda como atributos sueltos, puede convenir modelar Dinero. En lugar de calle, número, ciudad y provincia repetidos en varios lugares, puede convenir modelar Dirección. En lugar de horaInicio y horaFin sueltas, puede convenir modelar Rango horario o Franja horaria.

Convertir atributos en objetos de valor mejora la claridad cuando el valor tiene significado propio.

9.10 Atributos y reglas de validación

Los atributos suelen tener reglas de validez. Un correo electrónico debe tener un formato aceptable. Una fecha de fin no puede ser anterior a una fecha de inicio. Un porcentaje puede estar entre 0 y 100. Un importe puede no permitir valores negativos según el contexto.

Estas reglas deben expresarse como reglas del dominio cuando son importantes para el negocio. Si quedan solo como validaciones técnicas, pueden duplicarse, omitirse o aplicarse de manera inconsistente.

9.11 Atributos temporales e históricos

Algunos atributos cambian con el tiempo y puede ser necesario conservar su historial. Por ejemplo, una obra social de un paciente puede cambiar, una dirección puede actualizarse o el estado de un turno puede modificarse varias veces. El modelo debe indicar si solo importa el valor actual o si también importa la historia de cambios.

Si el historial tiene valor para el negocio, tal vez no alcance con un atributo simple. Puede ser necesario modelar eventos, registros históricos o relaciones con vigencia temporal.

9.12 Atributos sensibles o regulados

Algunos atributos requieren especial cuidado porque contienen información sensible, legal, médica, financiera o personal. En un sistema de salud, datos como diagnóstico, historia clínica, documento o información de contacto pueden tener restricciones de acceso y protección.

En el modelo de dominio conviene señalar que estos datos tienen importancia especial, aunque los mecanismos concretos de seguridad pertenezcan al diseño técnico. El análisis debe reconocer que no todos los atributos tienen el mismo nivel de riesgo.

9.13 Tabla de ejemplos

La siguiente tabla muestra distintos tipos de atributos en un dominio de turnos:

9.14 Preguntas para analizar atributos

Estas preguntas ayudan a decidir si un atributo pertenece al modelo de dominio:

• ¿Qué significa este dato para el negocio?
• ¿Quién lo conoce, lo registra o lo modifica?
• ¿Es obligatorio u opcional? ¿Por qué?
• ¿Participa en alguna regla, cálculo o decisión?
• ¿Se obtiene de otros datos?
• ¿Debe conservarse su historial?
• ¿Tiene reglas de formato, rango o validez?
• ¿Es un dato sensible o regulado?
• ¿Conviene tratarlo como objeto de valor?

9.15 Errores frecuentes

Al modelar atributos, suelen aparecer estos errores:

• Agregar todos los campos de un formulario al modelo sin analizar relevancia.
• Confundir datos de interfaz con atributos del dominio.
• Guardar datos derivados sin reconocer su dependencia de otros datos.
• No documentar reglas de cálculo importantes.
• Tratar datos compuestos como atributos sueltos cuando deberían ser objetos de valor.
• Ignorar si un atributo cambia con el tiempo y requiere historial.
• No considerar sensibilidad, privacidad o restricciones de acceso.

9.16 Qué debes recordar de este tema

• Un atributo del dominio debe tener significado relevante dentro del negocio.
• No todo campo de pantalla, formulario o tabla pertenece al modelo de dominio.
• Los datos derivados se obtienen a partir de otros datos.
• Los datos calculados dependen de reglas, fórmulas o políticas del negocio.
• La decisión de almacenar o calcular un dato pertenece al diseño técnico.
• Algunos atributos conviene modelarlos como objetos de valor.
• Los atributos pueden tener reglas de validez, historial y sensibilidad.

9.17 Conclusión

Los atributos ayudan a describir conceptos del dominio, pero deben seleccionarse con criterio. Un buen modelo no acumula datos sin sentido; muestra aquellos que explican reglas, estados, relaciones y decisiones importantes del negocio.

En este tema vimos cómo diferenciar datos relevantes, derivados y calculados, y cómo decidir cuándo un atributo merece convertirse en objeto de valor. En el próximo tema estudiaremos las asociaciones entre conceptos, prestando atención a vínculos, roles y dirección de lectura.