DDD in Practice

Hace ya varios meses que me estoy leyendo el libro de Eric Evans titulado “Domain Driven Design”. Su lectura está siendo muy reveladora porque, por ejemplo, me ha terminado de convencer de la necesidad de evitar los modelos anémicos frente a los modelos ricos. Pero hoy me he leido un artículo publicado en InfoQ sobre DDD que me “he bebido casi inmediatamente” y que ha resultado incluso más clarificador que el libro de Evans (que prometo terminar de leer, por supuesto).

El artículo de Srini Penchikala es denso: no es el típico articulito (como éste que estáis leyendo ahora mismo) que comenta de pasada, sin profundizar, uno o dos artículos más o menos conocidos, sino que aporta una estructura en el discurso y contenidos que aclaran mucho las ideas.

El autor explica qué aporta DDD en cada momento del desarrollo de una aplicación y cómo lo hace. Explica la sinergia entre DDD y SOA y llega incluso a hablar de cómo debe ser el framework en el que basemos nuestro desarrollo: POJOs, DI y AOP y, por supuesto, para todo debemos poder hacer pruebas unitarias lo más fácilmente posible.

Me gustaría destacar el comentario que hace sobre el uso de anotaciones y, en particular, la propuesta de uso de las anotaciones , o que ofrece Spring y que ya estoy tardando en probar.


Quiero sacar tiempo de donde sea para poder probar la aplicación de ejemplo. Tengo muchas ganas de ver cómo ha resuelto:
a) la separación finísima que suele existir entre capa de presentación y de aplicación
b) las distinción entre validaciones y reglas de negocio.
c) la separación a veces difícil de explicar (y justificar su existencia) entre objeto del dominio, “repositorio” y DAO

Creo que ahí es donde solemos fallar todos al implementar cualquier arquitectura, por bien definida que esté ésta en “la pizarra”. Bueno, yo más porque me temo que en mi proyecto actual tengo todos y cada uno de los “tufillos” (“smells”) que indica Penchikala que deberían ser evitados.

Me ha dejado absolutamente intrigado la referencia que hace sobre ROO (Real Object Oriented), que por lo que he podido encontrar haciendo “googling” ha sido que es un “toolset” que están preparando desde hace años los de SpringSource, pero del que aún no se ha liberado nada. De todos modos, quizás no sea mala idea echar de una vez por todas un vistazo a Grails, visto lo productivo que puede ser si se usa con la orientación adecuada.

Me ha gustado también mucho cuando enfatiza el uso de generadores de código porque coincido plenamente en la necesidad de identificar qué pasos del desarrollo se pueden automatizar y usar frameworks para ello. Éste es mi objetivo desde hace años, aunque todavía no he conseguido encontrar la combinación adecuada; quizás porque siempre termino cayendo en la trampa de los “dominios anémicos” y las “capas de servicio hinchadas” (“fat service layer”) con la vana esperanza de ahorrarme lineas de código.

Y por último, me apunto la idea de usar BNLs para especificar reglas de negocio o comportamientos de los sistemas (vamos, para hacer BDD o ATDD). Ahí, la sinergia con herramientas como Concordion resulta evidente…

Bueno, lo dicho, a ver si consigo sacar una tarde o dos para ver con detalle el código de la aplicación de ejemplo y saco alguna conclusión más. De momento, “en la pizarra” todo es muy, muy prometedor.

Tagged: