El camino hacia el Modelo de Dominio y Domain-Driven Design

Por años, la comunidad de desarrolo de software ha luchado contra la complejidad y el cambio. El desarrollo de software es uno de las actividades humanas con más niveles de detalle: debemos captar la imagen completa del sistema, y a la vez, tomar en cuenta cada pequeño detalle. Un desarrollador o un equipo de desarrolladores tienen que manejajar un montón de concptos, estilos de arquitectura, patrones de diseño e implementación, lenguajes, tecnologías, mejores prácticas y aún más: tiene que ejercitar los “soft skills” de comunicación con otros interesados en el proyecto.

Todo esto puede ser una tarea intimidante.

Muchos paradigmas emergieron en las últimas décadas, notablemente el orientado a objeto. Pero toma caminos divergentes: uno fue el purismo académico, con Smalltalkers y otros, que hicieron una gran tarea difundiendo objetos, pero que siguieron trabajando en aplicaciones, digamos, de nicho, no cruzando el abismo para llegar a la corriente principal de desarrollo (supongo que la fragmentación de Smalltalk en diverss dialectos fue una de las razones para el estado actual de la comunidad ST). No me malentiendan: Smalltalk tiene un comunidad fuerte y viva, pero no es uno de las tecnologías con muchas aplicaciones empresariales para mostrar.

C++ fue el primer lenguaje popular que dió “objetos para las masas”, pero con la aparición de tecnologías complicadas (¿recuerdan la API desnuda de Windows? ¿O cualquier API de GUI?) y la explosión del mercado de PC, la corriente principal de desarrollo fue tomada por lenguajes derivados de xBase, y Delphi y Visual Basic, este último no tiene soporte de objetos hasta la versión 3, y nunca soporte de herencia. (Visual Basic fue un “matador” de ideas hermosas, como el lenguaje Actor: una extensión orientada a objetos del lenguaje Forth, con soporte nativo de GUI, implementado en Windows). (Sí, también tomemos nota de COBOL: este lenguaje fue y aún es el lenguaje principal en muchos ambientes).

Java hizo su aparición a mediados de los 90, dando aire fresco a la programación (yo nunca programé con VB 6.0: después de encontrar el paraíso Java, quién quería lidiar con Apartment Thread Models y todo el lío COM). Teníamos una librería de clases, verdaderos objetos, pero más: nosotros fuimos bendecidos por un “garbage collector”, recolector de basura. Los nuevo “patrones de diseño” podían ser adoptados de forma masiva. Los objetos comienzan a estar en todas partes. Aparecen frameworks.

Pero algo estaba faltando: aunque los frameworks tomaron ventaja del uso de objetos, las implementaciones de negociones de muchas aplicaciones no reflejaban las nuevas capacidades. El elusivo Modelo de Dominio era un “santo grial” que no era fácil de encontrar. El trabajo de Sun con J2EE fué un fracaso parcial para armar modelos de dominio en Java. Cuando .NET nace, Microsoft no repite el error, y en sus primeros ejemplos y escritos de  Pattern and Practices, no usan ninguna de los ideas de Modelo de Dominio (supongo que todavía son reluctantes a adoptar un Modelo de Dominio, LINQ to SQL es aún una bestia orientada a datos, la esperanza que tenemos es el Entity Framework).

La comunidad de Java tiene un gran conjunto de herramientas y librerías de código abierto, desde Ant a Maven a Tomcat y más. La simplicidad de la programación POJO (Plain Old Java Objects), junto con soluciones no intrusivas de persistencia (notablemente Hibernate), tomó un nuevo camino para alcanzar una más clara implementación de un modelo de dominio.

.NET entró tarde en el juego: mucha de las herramientas y ejemplos en el mundo .NET eran centradas u orientadas a datos, con datasets, y características de enlace a datos en todas las presentaciones (WinForms y ASP.NET). La comunidad .NET aprendió de la experiencia de la comunidad de Java, y en los últimos años, tenemos las ideas de Modelo de Dominio implementado en ambos mundos.

Eric Evans escribió un libro seminal sobre sus ideas de Domain-Driven Development, donde el Modelo de Dominio no es un artefacto más, sino el corazón del software a desarrollar. El va más allá de Modelo de Dominio, describiendo nuevos patrones y maneras de implementarlo. El libro explica el proceso para crear y descubrir un modelo, usando un lenguaje ubicuo (compartido con los usuarios), y cómo mejorar el modelo a lo largo del proceso de desarrollo.

Implementaciones de modelo de dominio, y DDD, son grandes tópicos a tratar. Quiero comenzar a escribir sobre esos temas, discutiendo varios puntos, y dando ejemplos concretos en Java y .NET. No es una tarea fácil, así que no esperen un post diario: el trabajo tomará tiempo.

Por ahora, pueden visitar mi colección de enlaces sobre DDD en:

http://del.icio.us/ajlopez/ddd

Algunos de mis anteriores posts sobre DDD:

Mini Book Domain Driven Design Quickly

Domain-Driven Design Resources

Enlaces y Recursos Domain-Driven Design

Domain-Driven Design

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com

This entry was posted in 2884, 3463. Bookmark the permalink.

One Response to El camino hacia el Modelo de Dominio y Domain-Driven Design

  1. walter says:

    animo, esperamos tus futuros articulos

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>