Dudas y aportes al desarrollo de software

30/9/09

DDD no es todo

Terminado de leer el éste artículo me puse a buscarle otra pata mas al gato.
Hace tiempo que vengo pensando que DDD es una buena idea, mal llevada a cabo.
DDD nos dice, básicamente, que debo centrar mis esfuerzos en representar el modelo.
Agrega otras cosas, como "Ubiquitous Language", "Persistance Ignorance" y blah blah blah.
Ahora bien, yo creo que todo el que se sienta a desarrollar, tiene una idea de lo que quiere hacer... incluso desde tiempos inmemoriables cuando se programaba con palos y piedras. ¿Eso no es un modelo? ¡Claro! Si modelo es la representación de la realidad, con algunas acotaciones para hacerla manejable.

Entonces, ¿donde está la revolución? en OOP. DDD se apoya fuertemente en OOP (y sus patrones).
El core de mi dominio son mi Entities y mis Values Objects, y además se usan otros nombres, pero siempre orientado a objetos.

Ok, tengo que pensar mi modelo como objetos. Bien, no hay problema con eso.

Ahora viene lo bueno, he creado un modelo consistente con mi dominio (o negocio), pero tengo que hacer algunas otras cosas. Tengo que guardar los datos en algún lado, tengo que pedir datos que alimenten mi modelo, tengo que mostrar los resultados de aplicar las reglas de negocio... en definitiva, tengo que hacer mi sistema.

Pero... ¿el objeto de mi modelo no es serializable para mostrarlo? ¿Que hago? ¿Modificar el modelo? ¡Dios (y los puristas) me libre y guarde!
No hay otra opción, tengo que crear una capa de objetos serializables y mapear allí mis objetos de dominio, para poder enviar a la vista (supongamos en formato JSon).

Ahora tengo que guardarlos. Otra capa, no hay problema. ¿Que envío? ¿El objeto de mi modelo, u otro objeto mapeado? Lo segundo, seamos consistentes.

Ahora lo quiero envíar por TCP, es decir serializarlo en un stream de bytes. Otro objeto que mapee los datos de mi objeto de modelo.

Ah! tengo dos serializadores, los podría poner en uno solo! No sé... habría que renombrar mi clase JSonSerializer a MultiSerializer... pero ésto está en el framework... y lo están referenciando externamente otros programas que corren en batch (unos 180) No, definitivamente es mejor una nueva clase.

Y aquí es donde un solo objeto de mi modelo es mapeado a 3 objetos distintos (yo les llamo "de sistema"), según la necesidad.

Y tengo por ahora en mi sistema, 4 objetos vivos. Uno para persistir, 2 para serializar y mi objeto de dominio... y los 4 tienen los mismos datos, o partes de ellos.

Y así, agregamos clases y mas clases (los mas avezados, tendrán interfaces que en definitiva terminarán siendo implementada por alguna clase)

Y es así como la complejidad de los sistemas aumenta. Tenemos miles y miles de clases, tenemos que hacer refactoring introduciendo nuevos errores, tenemos el mismo dato en dos lugares, que si lo necesito para una cosa tengo que hacer A, y si lo necesito para otra tengo que hacer B. ¡ES EL MISMO DATO!

Es como dice el artículo al que hice mención en un principio. Estamos fallando al querer atajar la complejidad.

Ahora, ¿no sería mejor pensar en OOP, pero con un enfoque TOP-DOWN? Es decir, pretendo hacer un sistema. Bien, qué necesito para mi sistema? Un serializador, con dos métodos, un persistidor, y el objeto para que ellos lo usen. El objeto, debe ser suceptible de ser serializado y de ser persistido. No, mi dominio no lo requiere, pero mi sistema sí. Y yo, en definitiva, hago sistemas, no dominios.



Con seguridad, muchos dirán que el serializador se puede hacer de tal manera, el persistidor también, que el objeto de dominio puede salir de su dominio (rompiendo el principio de "Bounded context", aviso), he llegado a ver objetos de dominio, con sus métodos de negocio enviados a la vista. ¿Para qué quiere la vista esos métodos? Para nada, pero si están ahí ALGUIEN los va a usar.

¿Está mal la implementación? No sé, pero desde mi punto de vista, pensar en dominio primero sin tener en cuenta la noción de sistema es lo que está trayendo mas problemas que incluso una aplicación Data Driven Design.

Si alguien tiene estadísticas de si usando OOP, patrones, DDD, se consiguieron bajar los tiempos de mantenimiento, los bugs, o mejorar la performance de las aplicaciones, me encantaría leerlas.

Estoy seguro que se acortaron los tiempos de desarrollos... pero no estoy seguro de si tiene que ver con la evolución de los IDEs y demás herramientas; porque en definitiva, un objeto podría ser tranquilamente un módulo en uno de los programas de antes. (Y he visto programas en clipper mucho mas legibles que en C#)


Peguen, que estoy listo.

Seguidores