En el desarrollo de productos digitales los problemas de comunicación son frecuentes. Decimos que se hablan diferentes «idiomas» lo que puede generar malentendidos y otros problemas. Es aquí donde entra en juego el Domain-Driven Design (DDD), un concepto nacido en el mundo del desarrollo, pero cuyo enfoque centrado en el negocio nos es útil a los diseñadores de producto. Por eso, sin ser yo experto, veo relevante escribir esta entrada sobre el diseño dirigido por dominio.
De hecho, un disclaimer. En las empresas en las que he trabajado hemos aplicado el diseño guiado por dominio dentro de nuestra posibilidades y también he investigado un poco por internet para redactar esta entrada lo mejor posible. Sin embargo, lo cierto es que no soy un experto en el tema. Así pues mi obligación es referirte a quien acuñó el término: Eric Evans en su libro “ Domain-Driven Design — Tackling Complexity in the Heart of Software”.
Tabla de contenidos
Estos son los puntos que vamos a ver en esta entrada:
¿Qué es el domain driven design?
El Domain-driven-design es una metodología de trabajo propia de desarrolladores, no de diseñadores, pero dado que se implementa de forma holística en las empresas, también incide en el equipo de diseño y por eso es interesante conocerlo.
El diseño guiado por el dominio consiste en diseñar (en tanto que planificar) y ejecutar en base al dominio (el modelo de negocio). No tiene nada que ver con el dominio web, como te digo, aquí el dominio equivale al modelo de negocio.
Esta metodología es propia de dominios complejos por volumen de datos, de funcionalidades y previsiblemente de facturación. Probablemente no merezca la pena implementarlo en start-ups. Algunos ejemplos de dominio útiles pueden ser:
- Reserva de alojamientos estilo Airbnb o Booking
- Reserva de transporte estilo Ryanair o Renfe
- Sistema de gestión de empresa de logística estilo Correos, Glovo o incluso Cabify
- Sistema de gestión de empresa grande estilo Hospital
Fíjate que sí he puesto ejemplos de empresas que han sido start-ups pero no cualquier start-up, sino masivas.
Características del domain-driven-design
Bien, pues las características principales del Domain-driven-design son:
- Modelo de negocio
- Lenguaje ubicuo
- Contexto delimitado
- Entidades y objetos de valor
- Agregados, servicios y repositorios
- Eventos del dominio
Veamos en qué consiste cada uno de estas características y cómo nos podría afectar como diseñadores UX / UI o de producto. Con el ejemplo del software de gestión de hospitales.
Dominio como modelo de negocio
Como indicaba al responder a qué es el domain driven design, en esta metodología se considera que el dominio es el modelo de negocio. Por tanto, el modelo de negocio (dominio) es el centro desde el que nace todo. Por eso, el primer paso es comprender el negocio a través de expertos y usuarios quienes nos informarán del valor del producto / servicio, características, dificultades y restricciones.
Como diseñadores es imprescindible comprender las piezas con las que montar nuestro puzle.
Poniéndonos en el ejemplo que comentaba del software de gestión de hospitales, lo primero sería la comprender cómo funciona la gestión de datos hospitalarios (tipos de usuario, tipos de roles, tipos de ubicaciones, tipos de accesos, horarios, citas, contactos, historial clínico, nóminas,medicamentos, material, proveedores, etc.). En este caso, a su vez esto viene precedido por el modelo de negocio de atención sanitaria.
Lenguaje ubicuo
Esto se resume en la 2ª heurística de Nielsen de correlación con el mundo real. Algo normal para nosotros diseñadores pero no tanto para los desarrolladores y otros grupos de interés. Consiste en someter toda la comunicación a la jerga del dominio, lo cual incluye la experiencia de usuario y el desarrollo. Así pues, todo el equipo hablará el mismo idioma, el del negocio y que por tanto acostumbra el usuario, y se evitarán malentendidos entre los diferentes individuos involucrados en el desarrollo.
Con esta metodología en el código veremos paciente y no user, consulta y no date, quirófano o planta y no room.
Contexto delimitado
Los sistemas grandes se dividen en partes más pequeñas. Lo mismo ocurre con los dominios. Cuando el dominio excede cierta complejidad, necesita dividirse en subdominios. Cada uno de ellos delimitado por unas reglas, conceptos y terminologías determinadas. Es a lo que llamamos contexto delimitado.
Por tanto, los contextos delimitados (bounded context) son áreas aisladas que sin embargo pueden interactuar y comunicarse con otras. Suponen un beneficio a la hora de trabajar primero porque dan claridad en tanto que reducen la complejidad del dominio y permiten ver y comprenderlo a través de estas áreas más pequeñas. Además, simplifican la manera de hacer cambios en las diferentes áreas ya que están más aisladas al estar por grupos.
En cuanto a diseño, los bounded context son la piedra angular de la arquitectura de la información pues establecen la navegación y la forma en que las interfaces agrupan y presentan la información. Esto se traduce en los diferentes flujos que podemos encontrar respecto a enlaces, reglas y lógicas. En nuestro ejemplo de la gestión de hospitales, un contexto delimitado sería la gestión de citas. La creación, cancelación y reprogramación de citas tendría unas condiciones propias e interactuaría con otros contextos como los pacientes o los empleados.
Entidades y objetos de valor
Las entidades son elementos que tienen una identidad única que se mantiene constante a lo largo del tiempo, incluso si sus atributos cambian. Por ejemplo, cada paciente tiene un ID único aunque su dirección, historial o incluso nombre pueda cambiar.
Los objetos de valor son elementos que se definen únicamente por sus atributos y no tienen una identidad propia. Son inmutables, lo que significa que en lugar de modificarse, se reemplazan por otros. Por ejemplo, las fechas son objetos de valor. Se pueden reemplazar pero no editar, lo que se edita es la cita.
Como diseñadores es fundamental entender las entidades y objetos de valor pues así se establecen jerarquías y se marca la arquitectura de la información.
Agregados, servicios y repositorios
Los agregados son la suma de entidades y objetos de valor que, en conjunto, forman esta unidad dentro de un contexto limitado. Los agregados se controlan desde la llamada entidad raíz, que es la que sirve para comunicar el agregado o alguna de sus partes internas con otros agregados.
Si usáramos un sistema atómico similar al del diseño atómico para explicar estas relaciones tendríamos lo siguiente:
- Agregado = Átomo. Unidad fundamental de consistencia que contiene subelementos.
- Entidades = Protones y neutrones
- Objetos de valor = Electrones
- Contexto delimitado = Molécula. Puede contener un solo átomo o varios.
Retomando el ejemplo del software para gestionar hospitales podemos tener los siguientes agregados:
| Agregado de paciente Entidad raíz: Paciente Otras entidades: HistoriaMedica, Cita, Doctor, Diagnóstico | Agregado de cita Entidad raíz: Cita Otras entidades: Paciente, Doctor, DetallesCita | Agregado de doctor Entidad raíz: Doctor Otras entidades: Consulta, Horario, Especialidad |
Por tanto el agregado paciente se conecta con el agregado de cita a través de la cita, ya que un paciente puede tener múltiples citas programadas. A su vez, la cita se conecta con el doctor ya que la cita puede atribuirse a varios doctores.
Los servicios representan operaciones que no se ajustan naturalmente a ninguna entidad o valor dentro del dominio, pero que son esenciales para el negocio. Además, a menudo realizan operaciones que afectan a varios objetos de dominio o cuando el comportamiento no puede ser naturalmente asociado con una sola entidad.
En nuestro ejemplo el servicio GestionarCitasServicio sería responsable de la lógica relacionada con las citas. Esto incluye programar, cancelar o reprogramar citas para los pacientes. Para ello usaría los métodos ProgramarCita, CancelarCita o ReprogramarCita.
Los repositorios son un patrones de diseño que actúan como bibliotecas guardando y almacenando información, lo cual facilita a los desarrolladores la recuperación de datos y trabajar directamente con los objetos del dominio, en especial con agregados completos, sin exponer los detalles técnicos. En otras palabras, manteniendo las reglas y códigos del dominio.
Por ejemplo, un repositorio de horarios podría facilitar la creación o edición de servicios para AgregarHorario, EliminarHorario, ActualizarHorario, BuscarHorario, AsignarHorario, etc.
Eventos del dominio
Los eventos de dominio son una herramienta poderosa en DDD que facilitan la comunicación, el desacoplamiento, la auditoría y la integración en el sistema. Capturan y comunican cambios significativos en el modelo de dominio, permiten construir sistemas más robustos y flexibles, lo que es crucial en entornos complejos como la gestión de hospitales.
Estos eventos son parte de la primera heurística de Nielsen. Por eso, como diseñadores debemos prestar atención a su tratamiento para que haya una comunicación efectiva de aquellos eventos del dominio que puedan interesar al usuario.
Analizándolo desde el ejemplo que hemos tratado durante toda la entrada, estos eventos registrarían información tan importante como las citas programadas, las citas canceladas, las recetas asignadas, los doctores o enfermeros asignados, etc.
