Friday, July 10, 2015

Bounded contexts en Domain Driven Design


En el AOS 2015 de Gijón me apunte a una Sesión de Diseño con DDD (@carlospeix), se uso un ejemplo del grupo de ddd-es para iniciar una conversación sobre el posible diseño de un pequeño modelo. Después de la sesión, comente con Carlos la importancia que tiene comenzar a aprender DDD centrandose en la division en Bounded Contexts/subsistemas y en el lenguaje de domino de cada uno de estos Bounded Contexts, en vez de centrarnos en modelado estático (entidades y relaciones) que puede derivar en que intentemos modelar de forma global todo el dominio del sistema (con la complejidad que tiene y el riesgo de hacer una megaconstrucción que no se pueda mantener).

Carlos me propuso explicar mi punto de vista en un hangout público...

El hangout lo hicimos ayer y se puede consultar en la página del evento o en el video de youtube que subio Carlos a su canal:



A continuación unas notas y referencias relacionadas...

Domain Driven Design

  • Útil para dominios complejos
  • Nos centramos en el negocio y intentamos modelar el comportamiento y los procesos de negocio con la ayuda de expertos del dominio
  • Usamos el lenguaje de los expertos del dominio
  • Dividimos en bounded contexts/subsitemas
  • Cada bounded context se implementa con el modelo de dominio como parte central
  • Se dispone de ciertos tácticas/patrones para facilitar la implementación de estos bounded contexts (ValueObjects, Agregados, Entidades, Repositorios, Eventos de Dominio,  etc…)

En el libro DDD Tackling Complexity in the heart of software Software en el que Eric Evans presentaba está forma de hacer software, la descripción de Bounded Contexts y otros conceptos para hacer el diseño estratégico aparecen en la segunda parte del libro.
Y entre que el libro es bastante pesado de  leer y que en la primera parte se tocan temas más "divertidos" para los desarrolladores de software, el mensaje general que ha transcendido está mucho más centrado en las tácticas y patrones con el que implementar (agregados, repositorios, etc).


Posteriormente, Eric Evans en varias entrevistas ha comentado que lo central de esta forma de diseño es el lenguaje ubiquo y los bounded contexts.

“Ubiquitous Language and Context Mapping and Core Domain are at the center, with aggregates in close orbit. Why, I ask myself, did I put context mapping in Chapter 14? Core domain in Chapter 15?!” Eric Evans (What I’ve learned about DDD since the book)

Subdomains y bounded contexts

En el DDD exchange de este año Eric Evans y Udi Dahan llegaban a la conclusión que subdomains y bounded contexts tienen un mapeo 1 a 1, siendo los bounded contexts del dominio de la implementación. Así que dicho esto, de forma pragmática se puede considerar como bounded context cada uno de los sub sistemas  que conforman la implementación de un sistema complejo.

Por supuesto cada uno de estos bounded context/subsistemas:
  • tienen su propio lenguaje de dominio (una palabra puede tener distintos significados en cada uno de los bounded contexts)
  • internamente tienen gran cohesión
  • tienen un bajo acoplamiento con otros bounded contexts
  • para implementar cada uno de los bounded contexts podemos tomar distintas decisiones
    • tipo de arquitectura
    • infrastructura usada
    • incluso lenguaje de desarrollo

Por supuesto cada bounded context tiene sus propios datos, no están acoplados usando la misma BD compartida… (eso cae de cajón).

Esta forma de dividir los sistemas es muy compatible con un SOA bien entendido o lo que se está denominando como arquitectura de microservicios. En caso de crear bounded contexts que se comuniquen mediante eventos, también se facilita la creación de aplicaciones reactivas (http://www.reactivemanifesto.org/)

Ejemplo de descomposición en bounded contexts 

Supongamos que estamos encargados de implementar un sistema de venta online de viajes.
Durante el desarrollo nos centraremos en hablar con los expertos del dominio para ir extrayendo los comportamientos, acciones y eventos que se producen el sistema.
Por ejemplo podemos identificar las siguientes acciones:
  • Añadir hotel al catalogo
  • Realizar reserva en una cadena de hoteles
  • Cobrar una reserva
  • Recomendar un viaje a un viajero
  • Registrar experiencia de un viajero en un hotel
  • Generar billetes de avión
  • Cobrar reservas
  • etc...

De estas acciones, de los diversos departamentos de la empresa, de la información que necesita cada acción, de los eventos que se generan podremos ir identificando las los límites entre cada bounded context.
En el caso anterior puede que nos salgan bounded contexts como:
  • Catalogo de vuelos/hoteles
  • Sistema de recomendaciones
  • Contabilidad
  • red social de viajeros
  • ...
La verdad es que como no tengo ni idea de ese dominio, no se si estos bounded contexts tienen sentido, pero para el ejemplo pueden valer. :-)

En cualquier caso debe quedar la clara la importancia de hacer esta división y de implementar cada uno de esos subsistemas de la forma más autonoma posible. Esto permitirá tomar decisiones de forma flexible puesto que lo podremos hacer independientemente para cada bounded context.

Tendremos que decidir el estilo de comunicaciones que vamos a usar entre los distintos bounded contexts y los  patrones generales que vamos a usar en el sistema.
Luego podremos coger cada bounded context e implementarlo con la arquitectura, herramientas y enfoque que sea adecuado al problema a solventar (en vez de forzar un mismo enfoque para todo el proyecto).

Recursos

Por cierto que el resto de videos de Carlos Buenos Vinos sobre DDD están muy bien.

Una última nota

Si os ha parecido interesante y tenéis preguntas no os cortéis a ponerlos en los comentarios o por twitter (@carlospeix @eferro)
Lo mismo si os parece interesante que se hiciesen más hangouts sobre el tema invitando a más gente.

Cualquier opinión será muy bienvenida.


No comments: