El antropólogo de dominio. --Acerca de Domain Driven Design
Introducción
Si en mi última nota, publicada hace unos cuantos días atrás ya (¿o meses ? :( ), les comentaba acerca de los demonios hoy quiero comentar acerca de dominios que es el otro sujeto importante sobre el cual trata mi blog.
El Concepto de Dominio
Un dominio a decir verdad no es más que la formalización de la experiencia o el conocimiento que se tiene sobre un tema o un campo en particular.
Pero desde el punto de vista de nuestra profesión, los dominios comienzan a ser significativos después que Eric Evans, publica en Agosto del 2003 su libro titulado Domain-Driven Design: Tackling Complexity in the Heart of Software.
Domain Driven Design
Domain Driven Design [DDD] o Diseño guiado o regido por el dominio (y perdonen que no encuentre la traducción mas apropiada para el español) a decir del propio autor del libro, no es ni una tecnología, ni una metodología, es una forma de pensar que ayuda a entender el ámbito para el cual estamos desarrollando software y a formalizar todo el conocimiento que los expertos de dominio tienen en dicho ámbito, en un modelo.
Test Driven Design
DDD y TDD (Test Driven Design, Diseño guiado por Pruebas) van de la mano, como lo demuestra Jimmy Nilsson en su libro Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, y ambas formas de abordar el diseño de software no apuntan más que a: (a) acelerar y (b) hacer más productivo el proceso de desarrollo de aplicaciones para un determinado campo.
Desde el punto de vista del desarrollo de aplicaciones, si bien es evidente la complejidad, a la hora de descubrir los componentes u objetos principales de un dominio y de definir los atributos principales y las relaciones entre estos objetos que son significativos para el negocio, no es tan evidente la complejidad asociada a la representación de este dominio con las restricciones y las limitaciones que impone una tecnología en particular. Para lo primero y aquí voy a utilizar el término definido por otro autor David West en su libro Object Thinking, se necesita un antropólogo de dominio, para lo segundo un arquitecto avezado, alguien capaz de no perderse en la avalancha de incontables tecnologías y frameworks disponibles a la fecha.
División de Aplicaciones en Capas Lógicas
Entender las capas lógicas involucradas en este proceso es vital, para poder seleccionar la tecnología y las herramientas apropiadas que vamos a utilizar en este dominio. Hoy no es ajeno para nadie cercano a este campo del diseño, el escuchar hablar de capas de objetos de acceso a datos, de capas de servicios, de capas de objetos que representan el modelo de negocio y de capas de presentación.
Dos de las capas que no quiero dejar pasar por alto en esta nota son precisamente la capa de persistencia de datos y la capa de presentación. Después de haber encontrado nuestro modelo de dominio que representa fehacientemente nuestro modelo de negocios, es evidente que vamos a tener que exponerlo a nuestros clientes finales mediante una capa de presentación y además será necesario mantener el estado del mismo mediante una capa de persistencia.
Para resolver el problema de la capa de presentación, uno de los patrones mas comunes presentes en la mayoría de los frameworks disponibles en el mercado es el de modelo vista controlador o Model View Controller [MVC] y esta la nueva área de extensión en la que se encuentra trabajando el equipo de desarrollo de ASP.NET liderado por Scott Guthrie.
Para resolver el problema de la persistencia de datos hay varias alternativas dentro de la plataforma, la primera se acaba de liberar con .NET 3.5 y es conocida como LINQ to SQL y la segunda, esta muy próxima a liberarse y hasta la fecha ha sido conocida como Entity Framework.
Próximamente!
En nuestras próximas notas estaremos hablando de estas tecnologías y de las distintas alternativas que han ido evolucionando en el mercado para resolver el problema.
Conclusiones
A manera de resumen me gustaría decir que conocer estas tecnologías, sus escenarios de uso y sus limitaciones es importante no por lo novedoso o fácil que resulte usar o aprender cada una de estas tecnologías en particular, sino precisamente porque teniendo resuelto de manera eficiente cada una de estas capas, vamos a poder invertir mucho mas tiempo, en el descubrimiento del dominio y de sus componentes, lo que nos permitirá construir mejor software mas alineado con los requerimientos y las necesidades del negocio y mas adaptable a sus posibles escenario de evolución.
))) Alejandro Pacheco
Espero que esto les sirva. Gracias por su visita.
