lunes, 4 de febrero de 2013

Arquitecturas para Domain-Driven Design - Parte II

En esta entrada sobre Arquitecturas para DDD voy a hablar sobre...

Bounded Contexts

En un sistema grande y muy complejo es muy fácil que dos personas tengan interpretaciones distintas de un mismo concepto, o que repliquen dicho concepto en algún objeto por no saber que éste ya ha sido implementado en otra clase. La solución a esto pasa por definir contextos dentro de los cuales los modelos tiene una validez.

Los modelos grandes los vamos a separar en varios modelos de menor tamaño, estableciendo que, dado un elemento determinado de nuestro sistema, éste sólo tiene sentido dentro del contexto donde está definido. Nos centraremos en mantener la coherencia dentro de estos contextos y trataremos aparte las relaciones entre contextos.

Es fundamental definir, simultáneamente a los contextos, un mapa de los mismos, donde se establecen claramente los distintos contextos existentes en el sistema y las relaciones entre ellos. De esta forma obtenemos las ventajas de coherencia y cohesión que nos ofrecen los contextos y preservamos la visión global del sistema, estableciendo claramente las relaciones entre aquellos.

Esto, en definitiva, es fácil de ver si tenemos, por ejemplo, un sistema en el que podemos gestionar clientes y otro sistema que gestiona cuentas bancarias. Es más que obvio que debemos tener dos contextos diferentes: El modulo de gestión de clientes, con todas las operaciones aplicables a los clientes y el modulo bancario con toda la gestión de cuentas.

Una vez definidos esos contextos, con sus fronteras estrictamente establecidas, es fácil para cualquier desarrollador implementar un proceso del sistema sin caer en ambigüedades o reimplementar conceptos ya modelados. Si, por ejemplo, el proceso implica acciones contra cuentas corrientes y clientes, es trivial referirse al modulo bancario y al de clientes, y mirar las funcionalidades que expone cada uno. Si todo está correctamente modelado (incluidas las relaciones entre módulos), debería ser la cosa más sencilla del mundo coordinar esas funcionalidades para modelar cualquier proceso.

No hay comentarios:

Publicar un comentario