Nos acercamos a la cafetería “DeDD Café”. Al entrar, un camarero robótico nos llama por nuestro nombre y nos informa del menú y de las últimas novedades. Nos acercamos a la puerta y esta se abre automáticamente. La climatización, la música y la silla se ajustan a nuestros gustos. Antes de darnos cuenta, nuestro café favorito ya está servido. Podemos leer tranquilamente las noticias que más nos interesan y, cuando terminamos, nos marchamos de allí sin necesidad de sacar la cartera o el móvil para pagar.

La cafetería “DeDD Café” es una cafetería muy especial. Está completamente automatizada y está diseñada usando Domain Driven Design (DDD). En ella reconocemos varios dominios funcionales:

  1. Atención al cliente (AC)
  2. Climatización e iluminación (CI)
  3. Mobiliario y acomodación (MA)
  4. Servicio de bebidas y comidas (SBC)
  5. Almacén (A)
  6. Contabilidad (CON)

En cada uno de estos dominios, microservicios implementados por robots/sensores realizan funciones concretas asociadas. Los robots/sensores reciben y emiten eventos a través de un bus de eventos WIFI en el cual existen 7 canales, uno por cada dominio y otro general. Por los canales de cada dominio se transmitirán eventos de dominio (ED) y por el canal general, eventos de aplicación (EA).

Todos los robots están subscritos al canal de su domino y al canal general. Reciben todos los eventos de los canales a los que están suscritos, pero solo reaccionan de manera reactiva ante los que tienen alguna función programada. Existe un servicio centralizado de datos de cliente (DCLI) que escucha los eventos del sistema, actualiza los datos de los clientes y expone un servicio optimizado de consulta abierto a todos los robots y sensores.

El mejor reclamo: Sentirse cómo en casa

Supongamos que un cliente se acerca a la puerta de nuestro “DeDD Café”.

Al llegar, el sensor que está encima de la puerta captura datos biométricos, por ejemplo, los relativos a su cara, y consulta en el servicio DCLI para obtener el historial y los gustos del cliente.

Si es la primera vez que el cliente pisa la cafetería, el sensor emite un evento ED-ClienteCreado con los datos biométricos del cliente y un identificador único de cliente en el domino AC.

El evento lo recibe:

  • El servicio datos de cliente DCLI y, en consecuencia, inserta el nuevo cliente en su base de datos.

Además, tanto si es la primera vez como si no, el sensor emite otro evento ED-ClienteInteresado con el identificador único del cliente por el canal del dominio Atención al Cliente, AC.

El evento lo reciben:

  • El robot con cara humana situado en la puerta. Entonces, si el evento ED-ClienteInteresado no tiene nombre, se lo pregunta y muestra un vídeo atractivo de presentación de la cafetería. Si ya conoce el nombre y sus preferencias, se las menciona y le hace una sugerencia en función de la hora y la temperatura exterior.
  • El mostrador, que se ilumina mostrando las muestras de bollería.

Un buen recibimiento

Cuando el cliente se decide a entrar, el sensor de encima de la puerta emite el evento EA-ClienteDecidido por el canal general con el identificador único del cliente y lo reciben:

  • La puerta (dominio MA), que se abre
  • El climatizador (dominio CI), y entonces se activa para regular la temperatura del local a gusto del cliente si tienes esta información o a la temperatura por defecto.
  • La iluminación (dominio CI), y entonces se encienden las luces del local. Si existe información del cliente ajusta la iluminación al gusto del cliente.
  • El robot con cara humana (dominio AC). En este caso, si en los datos de cliente existe un historial de consumo, le sugiere algo acorde a sus gustos, la hora y la temperatura externa. En caso contrario, le pregunta que desea tomar. Con la información del cliente emite un evento de dominio ED-ClienteModificado, por el canal del dominio AC, que recibe el servicio DCLI (dominio AC), que modifica los nuevos datos del cliente.

Aquí saben lo que quiero

Al pasar por debajo de la puerta la propia puerta emite el evento de aplicación EA-ClienteHaEntrado con el identificador único del cliente y lo recibe:

  • La cafetera (dominio SBC), y empieza a preparar el café favorito del cliente. Entonces, emita EA-CafeConsumido por el canal general.

En este caso el evento es recibido por:

  • La caja (dominio CON), tras lo cual apunta un café en la cuenta del cliente.
  • La despensa (dominio A), que comprueba cuanto café queda y si es necesario emite un evento de dominio ED-CafeAgotado.
  • La silla (dominio MA), y se ajusta según las preferencias del cliente consultadas en servicio DCLI. Si el cliente la vuelve a ajustar, lanzaría un evento EA-ClienteModificado con las preferencias de la silla.

Hasta pronto, ha sido un placer

El cliente termina su café y se dispone a abandonar el local. Esta historia termina cuando el sensor de la puerta emite el evento EA-ClienteHaTerminado y lo recibe:

  • La caja (dominio CON), que cobra el total de la factura en el móvil del cliente y emite un evento EA-ClienteHaPagado.

Este evento lo reciben:

  • La puerta (dominio MA), que entonces se abre.
  • El climatizador (dominio CI), y desactiva la climatización del local volviendo a la temperatura de mínimo consumo.
  • La iluminación (dominio CI), y entonces se apagan las luces del local.
  • El robot con cara humana (dominio AC), tras lo que se despide del cliente amablemente, le informa del tiempo y le desea un buen día.

Este comportamiento, a modo de ejemplo, sirve para entender que los eventos que traspasan la frontera de un dominio funcional son eventos de aplicación y los que se circunscriben a la funcionalidad de un solo dominio son eventos de dominio.






¿Te gustaría recibir nuestros próximos artículos?