Quiero recomendar a toda la comunidad de desarrolladores de habla hispana que vean estos excelentes vídeos de Erick Evans que habla sobre DDD. Aunque están en inglés se los recomiendo, y para los que no entienden mucho el inglés les ofrezco el resumen que detallaré abajo.
Detalle a continuación la información desarrollada en la primera parte del vídeo, titulado "poniendo el modelo a trabajar".
http://www.infoq.com/presentations/model-to-work-evans
Inicia con una pregunta:
Porque nos debe de importar el modelo?
Y responde de la siguiente manera:
La complejidad crítica de la mayoría de proyectos de software esta en comprender el dominio del negocio en si mismo.
Aunque no es cierto para todos los dominios, si es cierto para la mayoría de aplicaciones para negocios. En vez de enfocarnos en la tecnología, nos enfocamos en resolver la complejidad del negocio. Es importante mencionar que no es aplicable para todos los dominios porque de esa forma podemos saber que la aplicación de un modelo orientada a dominios no va a funcionar en esos particulares dominios, no así para los dominios que si se aplica este estilo de ver las cosas, donde se puede aplicar un modelo.
Y esto nos lleva a definir sobre el dominio, y lo define así:
El dominio es una esfera de conocimiento, influencia o actividad.
El área del asunto en el cual el usuario aplica un programa es el dominio del software.
Dio ejemplos sobre un dominio, puede ser Banca, La gente vuelva en aviones y como las ponemos en el avión, las llevamos y las entregamos en otro lugar, Embarque.
En la mayoría de casos nos topamos que ya existen aplicaciones, y por tanto tenemos que trabajar con ellas. Y en la mayoría de casos podemos encontrar defectos en el diseño. Y antes de decidir cambiar algo debemos de profundizar en el modelo, preguntándole a los expertos del dominio, a la gente de negocios, para comprender mejor el modelo, la cual es nuestra orientación.
Debemos de preguntarnos que conceptos del modelo estamos olvidando o no conocemos, ya que estamos centrados en el modelo, para ello debemos de generar una tormenta de ideas con los expertos del dominio, y empezar a dibujar o modelar el dominio, con un lenguaje que manejan los expertos del domino, nada técnico, nada que tenga que ver con tecnología. Esto no solo es "barato" sino que efectivo.
Luego hizo la siguiente pregunta:
Que es un modelo?
Y para ello dio, un par de ejemplos, uno fue un mapa de china, según los chinos, y otro un mapa del mundo. Pero este ultimo el mapa fue diseñado para un propósito especifico y fue para la navegación. Y para ello fue hecho, no le importa, la población, ni que país es mas grande sino para lo que fue diseñado.
Entonces el modelo lo define así:
Un sistema de abstracciones (Mostrando todo acerca de algo, abstracción es excluye todo, excepto algunas particularidades en las cuales esta interesado) que describe aspectos seleccionados de un dominio, y puede ser utilizado para resolver problemas relacionados a ese dominio.
Concluye entonces que:
Un modelo sirve para un particular uso.
No es como sea realistico como sea posible, no es por el particular uso que el dominio dicta.
Cualquier modelo que permita al software entrar al dominio es un modelo que podemos utilizar.
Si podemos reflejar el modelo en el código encontraremos un nuevo nivel de utilización.
Cuando modelamos debemos escoger un escenario lo mas concreto posible.
Explica que no se puede reducir la complejidad del dominio, pero si la complejidad técnica, algunas veces. Y puede que se comprometa el dominio para bajar la complejidad, y eso no es problema porque no solo hay un modelo, sino "n" modelos para resolver el problema del dominio.
Define lo que denomina Lenguaje Ubicuo:
Un lenguaje estructurado al rededor de un modelo de dominio y utilizado para todos los miembros del equipo para conectar todas las actividades de un equipo con el software.
Tenemos en este lenguaje en el modelo porque nombramos a los objetos no nombres que representan el modelo.
Tenemos que interactuar con otros modelos y cada modelo es valido por lo que fue hecho pero como los conectamos, como hacemos que se comuniquen. Mapeo de Contexto es una estrategia para ello. Y se trata de tener un mapeo que traduzca de un contexto del modelo a otro contexto.
Nos vemos en la segunda parte del tema
donde Erick Evans habla sobre el diseño estratégico.
Code4Fun!,
Manolo Herrera
No hay comentarios.:
Publicar un comentario