Excelentes Vídeos de Erick Evans acerca de Domain Driven Design Parte 2

En esta segunda parte resumiré a mi forma particular de ver las cosas, el vídeo de Erick Evans sobre el diseño estratégico, espero que sea de mucha utilidad y vean el vídeo en esta dirección:

http://www.infoq.com/presentations/strategic-design-evans

Hace una analogía entre un competencia de remo de un bote de 8 personas, y como esto no sucede en los equipos grandes sino en equipos pequeños que están bien coordinados , y conectados entre ellos. Este tipo de conexión es la que se necesita para que el proceso de modelado funcione. Esto simplemente no sucede en los equipos grandes. Por lo que plantea la siguiente pregunta:

Como hacer para que los equipos grandes produzcan el modelado que esperamos en proyectos largos y trabajen en armonía?

Esto nos lleva a la siguiente realista premisa:

No a lo largo de todo el sistema será bien diseñado.

Solamente una parte del sistema será bien diseñado, si comprendemos esto realmente avanzaremos, Erick ha visto como el deseo por tener todo el sistema bien diseñado, nos lleva al desorden de todo el sistema y quitándonos la oportunidad del verdadero valor de tener partes seleccionadas bien diseñadas.

Debemos de comprender que:

Los diseños de precisión son frágiles.

Los buenos diseños en grandes sistemas no duran mucho, no sobreviven en ese ambiente, hay tanto caso que cada quién toma algo del código y empieza ha cambiarlo.

Lo que necesitamos hacer es definir:

Boundaries

Es necesario establecer Limites entre nuestro buen diseño y el resto del sistema.

Para ello podemos tomar dos estrategias:

Context Mapping o Mapeo de Contexto

y Distilling the Core Domain o Destilando la parte medular del dominio.

En el caso de ejemplo de un dominio de Embarque hay dos modelos distintos hechos para resolver distintos problemas uno el registro de las rutas de los barcos y el otro el la Red de transporte para ver la eficiencia de cada viaje. No se desea tener dos diferentes modelos para el mismo dominio, pero esto es justificado porque son tan complejos los problemas que resuelven que se requiere de dos modelos pare resolver diferentes problemas. Hace mucho sentido esto y nos da una nueva perspectiva que resolver los problemas del domino.

Lo primero al tomar un proyecto lo que hace Erick es hacer un Mapa del contexto; que significa que modelos están involucrados en este proyecto. Cuales son los limites que utilizan y las relaciones que tienen entre ellos, y el lenguaje que ellos utilizan.

Un análisis upstream/downstream, nos permite ver los efectos que tienen los modelos que rodean del proyecto que vamos a realizar tanto los de arriba como los de abajo y analizar el efecto, influencia que tendrán los cambios que realicemos. Este análisis nos permite profundizar mas en las relaciones entre los modelos.

Entonces nos lleva a saber con que contamos y con que tenemos que vivir, por lo que decido construir una pared para que no se corrompa mi modelo, que Erick le llama Anti-Corruption Layer o Capa de Anti-Corrupción. Ya que no se desea mucho de la influencia que provenga del otro lado. Por lo que se pueden hacer puertas y definir la forma de como las cosas deben funcionar.

Debemos de cuidar de las fugas en el proceso de traducción entre modelos y por ello es preciso definir una frontera y explícitamente definir allí todas las traducciones para mantener el modelo bien definido.

Luego nos lleva a la siguiente pregunta:

Que es un Mapa

Y lo que quiso decir es dibuja el mapa tal cual es.

Luego Fix true Flaws, o corrija los defectos verdaderos.

Cambie la realidad, solo entonces haga un remapeo para que refleje la realidad.

Si somos realistas en el plan del proyecto podemos plasmar eso y mitigar los riesgos, y no estressar el proyecto, desde el inicio.

Los beneficios del Mapeo de Contexto es:

Validar la comunicación

Alinear la expectación entre equipos.

crear un ambiente con el cuales los modelos pueden ser efectivos.

La segunda estrategia es sobre:

Destilando el medula del dominio

Esto es algo que debemos reconocer, todo el sistema tiene la misma importancia.

Esto nos lleva a desconponer en tres categorías:

Generic subdomains, como la facturación es un subdominio que puede se encontrado en muchos dominios y es casi lo mismo para todos. No es particularmente tiene que ver con el dominio.

Supporting Subdomains, apoya alguna parte de lo que realmente necesitamos hacer. Como podría ser en el modelo de Embarque la búsqueda de la calendarización de embarques provistas por terceros en formato data-feed.

Core Domain, este a propósito lo escribió en letra pequeña y fue para indicar que la razón por la cual estamos haciendo el proyecto, la parte mas importante, una vez que es destilado y separado de los demás componentes podría ser pequeño, específico. En el ejemplo del Domino Embarque, si el modelo que desea diseñarse es para encontrar la ruta mas eficiente, la parte del ruteo de los barcos será la parte medular del domino, pero muchas veces esto no es tan obvió.

Dio un ejemplo sobre como dos de sus mejores programadores realizaron un excelente trabajo para manejar las zonas de tiempo, pero no pusieron atención a cual era la parte medular del dominio, y el proyecto fracaso. Para eso nos sirve este tipo de análisis para destilar el dominio en partes y encontrar la parte medular y enfocarnos en ella.

Que es lo que su sistema vale la pena escribir?

Por que no comprarlo?

No lo puedo comprar porque esto me hace diferencia a los demás.

Por que no contratarlo para que lo hagan?

No, porque quiero tenerlo cerca de mi gente de negocios.

Por que no construir al que lo genera?

No, porque es complicado y muy especifico.

Por lo que que vamos a esforzarnos y enfocarnos en desarrollar la parte medular del dominio y no necesariamente las demás partes.

Otra pregunta que se le hace a los expertos del dominio es?

Que nos hace a nosotros especiales?

Esto no lleva a descubrir la parte medular del dominio, con la información de los expertos del dominio nos puedan dar.

Así que los desafíos en los grandes y multi-equipos proyectos son:

Mantener la integridad del modelo

Enfocar el esfuerzo (en lo que si va a dar resultado)

Ver el bosque para los árboles (Necesario conectar lo todo)

Unir la estrategia con la implementación

Debemos separar el diseño en diferentes formas a través de la destilación de la parte medular y no medular del dominio.

Salvese de la dicotomía arriba-abajo/abajo-arriba. Hay que ver el problema del dominio en todos los ángulos.

Espero les sirva, y abra un nuevo nivel de entendimiento del modelado de los dominios.

Design4Fun!,

Manolo Herrera