domingo, 12 de octubre de 2008

El Dominio Es Lo Único Importante

La capa de negocio es la más importante porque es la única que no depende de la tecnología. Comúnmente se le llama Aplicación a lo que comprende las capas de presentación, acceso al negocio y persistencia, y Negocio específicamente a la capa de dominio.

Tiers de Aplicación:
  • Presentación
  • Acceso al Negocio
  • Persistencia
Tiers de Negocio:
  • Capa de dominio
Esta separación parece trivial, pero encierra conceptos fuertísimos que implican una forma de llevar la programación de una aplicación sencilla, tradicional, a una aplicación compleja como es una enterprise.

El dominio no depende de la aplicación

El primer concepto es que el dominio no depende de la tecnología o aplicación. Al no depender de la aplicación, tenemos aislado lo que es el módulo donde trabajarán fuertemente los analistas funcionales para representar el negocio en un modelo. Este modelo o dominio, que no es más que un conjunto de objetos y clases interrelacionados al mejor estilo de la programación orientada a objetos, es el negocio, y puede ser reutilizado en distintas aplicaciones, puede ser desenganchado de una aplicación e injertado en otra, con una tecnología completamente diferente, como si se tratara de una pieza de Lego.


Tiers V.S. Layers

El segundo concepto es que la arquitectura del dominio es independiente de la arquitectura de la aplicación. Y aquí nos encontramos con una primera disonancia conceptual, que nos lleva a clasificar las capas en físicas (tiers) y lógicas (layers).
  • Capas Físicas o Tiers: Son las capas que ya estuvimos viendo en el post anterior. Se llaman capas físicas porque en general son las más propicias a ubicarse en servidores distribuidos físicamente. Podemos contar, por ejemplo, con un servidor de aplicaciones distribuido, el SGBD podría ubicarse en un servidor, el dominio podría ser accedido de forma remota (mediante RMI o similar), el acceso al negocio podría ser consumido quizá mediante SOA por diferentes plataformas y/o dispositivos y los clientes ni hablar que podrían ser muchos y ubicarse en cualquier parte del planeta. De todas formas, aunque no tengamos servidores disgregados en el espacio, separar la aplicación en capas físicas nos ayuda a distribuir la lógica de la aplicación.
  • Capas Lógicas o Layers: Estas capas nos sirven para separar las incumbencias en la lógica del negocio. Si bien cualquier capa física, por dentro, podría contar con varias capas lógicas, en este post lo que más nos interesa es concentrarnos en la lógica de dominio. Por eso, cuando me refiera a layers, me estaré refiriendo a las capas lógicas que viven en el tier del dominio. Cuando un dominio es muy complicado y extenso, a menudo resulta útil para el analista y/o diseñador optar por una arquitectura de capas, donde en cada capa vivirán distintos paquetes que sólo se relacionan entre sí y con unos pocos paquetes de la capa inferior, o para ser más prolijos, con la interfase que publica la layer inferior.

Domain-Driven Design

El tercer y más trascendente concepto es que el dominio es lo único importante. Es una idea fuerte, básica, simple, y muy difícil de aceptar y/o implementar. Por eso es que no se suele aplicar en muchos ambientes de desarrollo, donde parece que la tecnología y la forma de resolver los requerimientos no funcionales es lo más prioritario.

Domain-Driven Design (DDD) es un conjunto de buenas prácticas, patrones y recomendaciones para construir software sólido y robusto a partir de la creación del dominio. Las bases fundamentales de esta forma de trabajar fueron establecidas por Eric Evans en su famoso libro: Domain-Driven Design: Tackling Complexity in the Heart of Software (ISBN: 0-321-12521-5). Eric Evans es un defensor fanático de esta idea de que el dominio es lo único importante y propone que todo el desarrollo de una aplicación (sea enterprise o no), debería ser guiado por el dominio. Yo no he leído el libro completo, pero sí un resumen gratuito del mismo, llamado Domain-Driven Design Quickly, que fue elaborado por Abel Avram y Floyd Marinescu para el popular sitio de diseño y programación de software InfoQ y puede descargarse libremente desde aquí simplemente registrándose (la registración también es gratuita).

Domain-Driven Design está dividido en dos grandes incumbencias:

  • La construcción de buenos Modelos (Model-Driven Design): donde se introducen los patrones Entities, Value Objects, Services, Modules, Aggregates, Factories y Repositories, que sirven para la construcción efectiva de un modelo de negocio correcto. Evans establece el polémico concepto de lenguaje ubicuo, en el que propone que todos los integrantes de un equipo de trabajo (incluyendo los clientes y expertos del dominio) deben comunicarse utilizando una misma terminología. Esta terminología en general será la del experto del dominio o, en algunos casos excepcionales, la que el analista funcional estableció mediante mutuo acuerdo con el experto del dominio. Evans explica que es importante que en toda comunicación, verbal o escrita, que se efectúe dentro del marco del proyecto, se utilice el glosario que el analista y el experto del negocio convinieron, inclusive si la charla es entre programadores. Esta imposición acarrea un corolario polémico y fascinante: no sólo el modelo de dominio y los diagramas de diseño deben usar este lenguaje, también el código fuente. Evans propone un código escrito a muy alto nivel, donde los nombres de cada objeto y/o componente del código (sea método, clase, variable, paquete, etc) sean extraídos directamente del glosario del lenguaje ubicuo.



  • La preservación de la integridad del Modelo: no sólo es importante construir un buen modelo, también es fundamental mantenerlo. Muchos de los conceptos de Eric Evans van de la mano de la filosofía de las metodologías ágiles. Evans nos dice que si hay modificaciones en el código o el diseño, deben ser reflejadas automáticamente en el modelo y, si hay modificaciones en el modelo, deben ser reflejadas en el diseño y en el código. Esta segunda parte del libro habla de refactorear constantemente, de actualizar periódicamente el glosario del lenguaje ubicuo, de reconocer los conceptos claves del modelo y mantenerlos vigentes a lo largo de todo el proceso de desarrollo. A medida que los dominios van creciendo, van apareciendo patrones a nivel macro y formas de separar contextos y de distribuirlos de diferentes formas para facilitar el desarrollo. Es aquí donde entra más que nada el mundo de las aplicaciones enterprise, porque si de ellas hablamos, hablamos de negocios complejos y de dominios extensos. Evans presenta los patrones de Bonded Context, Continuous Integration, Context Map, Shared Kernel, Customer-Supplier, Conformist, Anticorruption Layer, Separate Ways, Open Host Service y Distillation, que atacan de diferentes formas la escalabilidad y reorganización de modelos grandes.


La importancia de un dominio portable

Todo esto nos lleva a la idea de construir un dominio portable. El negocio es el core, la estrella única e indiscutida de toda aplicación enterprise. Hoy en día los frameworks que hay en el mercado que logran la portabilidad del dominio son pocos. El framework es parte de la tecnología, pero como su nombre lo indica es el marco de trabajo del desarrollo de software. En mi opinión, si somos estrictos con las enseñanzas de DDD, llamarle ingenuamente framework a una herramienta de trabajo es contradecir la filosofía de DDD. Deberíamos llamarle framework al modelo, al dominio, y no a la tecnología que usamos para construir la aplicación que ejecute ese dominio.

En los comienzos, y durante muchos años, las aplicaciones enterprise fueron diseñadas en base a la tecnología, y creo yo que la culpa, en gran parte, la tuvieron metodologías como RUP, que son orientadas al plan y a los casos de uso, y ofrecen baja adaptabilidad al cambio. Las metodologías ágiles, como Scrum por ejemplo, son más compatibles con la construcción iterativa de modelos y de desarrollos guiados por el modelo y no por los casos de uso.

Hoy en día contamos con herramientas o plataformas que son compatibles con las filosofías de DDD y que nos ofrecen una forma de construir la aplicación sin resultar intrusiva con el dominio. Spring es una de ellas, Seam es otra que está tomando mucha fuerza (de la gente de JBoss que parece decidida a convertirse en líderes de tecnologías java para aplicaciones enterprise). Las enseñanzas de Eric Evans están tomando tanta fuerza en los últimos tiempos que Sun Microsystem ha tenido que replantear su pesada e intrusiva plataforma de EJBs y así fue como surgió la flamante especificación EJB 3.0, que incluye la especificación JPA para persistencia la cual respeta casi religiosamente el modelo de desarrollo de DDD. El cambio de paradigma exigió que a los viejos y queridos objetos de una aplicación Java común y corriente, se les cambiara el nombre de objetos a POJOs (Plain Old Java Object), de los cuales hace uso EJB 3. En el blog de tecnologías java, junto a Paola Grajeda, hemos dedicado algunos post teóricos y prácticos a EJB 3.0 y es muy posible que sigamos escribiendo al respecto (Ver: http://tecnologiasjava.blogspot.com/search/label/EJB 3).

La importancia de un dominio portable, independiente de la plataforma y de la tecnología, es crucial para el mundo de los negocios. La evolución más actual de todo esto son las aplicaciones orientadas a servicios (SOA), donde todo diseño es sublevado al negocio y a la flexibilidad y al cambio. Las interfases deben ser contratos de negocio, auténticos servicios a consumir por los expertos del dominio. Los servicios hablan de los casos de uso, pero el dominio puede también seguir esta filosofía utilizando la doctrina de DDD.

El lema de una las herramientas inspiradas en DDD, muy poco conocida, llamada Roma dice: "Piensa en el dominio, construye el modelo en simples clases Java, escribe la lógica de negocio y Roma hará el resto". Suena ambicioso. Eric Evans, en DDD, propone asignar a los analistas programadores más experimentados la construcción de las clases y paquetes del dominio y, al resto de los programadores con menor señority, la configuración de la plataforma, en otras palabras: la aplicación.

Conclusión

Si analizamos la historia de la Ingeniería del Software, podemos llegar a la conclusión de que la madurez de los procesos de desarrollo (no sólo de aplicaciones enterprise) se ve en el grado de separación de incumbencias entre la lógica de negocio y la lógica de aplicación. La construcción de sistemas de software ha comenzado siendo muy técnica para derivar cada vez más en abstracciones y nuevas abstracciones hasta alcanzar un objetivo final: modelar y programar procesos de negocios independientes de la tecnología.

En el siguiente post, basándome en el famoso libro de Martin Fowler: Patterns of Enterprise Application Architecture y en las fabulosas clases de Arquitectura de Software que el Ing. Guillermo Pantaleo dicta en la FIUBA, escribiré sobre los patrones enterprise que nos permiten lograr esta separación entre negocio y aplicación y las formas en que una arquitectura enterprise puede estar diseñada, independientemente de la plataforma y/o lenguaje de programación.

Entradas Relacionadas: