Nombrar cosas es bastante complicado. Más aún cuando el grupo que usará esos nombres no tiene el mismo background o provienen de áreas diferentes. Normalmente conduce a la confusión, a los malentendidos y, al final, a los errores.
¿Qué hacemos entonces cuando necesitamos migrar datos desde un sistema antiguo, moverlos hacia Magento y hacer que lo revise un departamento de finanzas o no técnico?. Todo ello por personas que no saben nada sobre los sistemas del otro o las convenciones de nombres.
… Comenzar con una taza de café y pensar en la mejor manera de lidiar con esto en lugar de estar lanzando una gran cantidad de datos de un lado hacia el otro esperando el mejor resultado.
Porque eso es lo que he hecho en innumerables ocasiones. Sentarme con un desarrollador de la otra plataforma o, en el peor de los casos, una persona no técnica que ejecute la exportación. Luego, hablar sobre cada columna de un CSV o XML hipotético tratando de descubrir qué es lo que realmente hace, y finalmente importarlo en Magento creando nuevos objetos o mediante consultas SQL directas. Generalmente funciona para el 90-95% de los datos, pero deja una gran cantidad de casos extremos que pasan desapercibidos o tienen que ser reparados manualmente.
Voy a comenzar diciendo que no podría haber hecho esto sin dos desarrolladores maravillosamente hábiles a mi lado que tenían mucha experiencia y paciencia. Pero necesitábamos algo que nos hiciera discutir sobre las varias entidades, los clientes, pedidos, facturas y los procesos a través de los cuales podíamos hacerlas más simples.
Recomiendo leer acerca de Domain Driven Design, que es un enfoque fascinante para el desarrollo de software que se enfoca en colaborar con las personas que entienden el negocio o el dominio y lo forman en un modelo que se utilizará para crear una solución. Sin embargo, esta descripción no le hace suficiente justicia. Van a encontrar un link a un artículo publicado recientemente por Eric Evans sobre DDD al final del post.
Para nuestras migraciones de datos hemos tomado 2 conceptos de DDD: el modelo de dominio y el contexto delimitado.
Dejamos de lado las extensas reuniones de inicio del día. Comenzaron a darse unas breves reuniones en las que describimos algunos de los desafíos que esperábamos y definimos quién era el experto en qué plataforma. Después de eso, rápidamente nos decidimos por la idea de construir una capa intermedia que extrajera datos de la plataforma anterior, almacenara en una base de datos separada y transformara los datos exactamente a lo que Magento necesitaba antes de que se transmitieran. Los detalles de esta implementación se dejaron para un momento posterior.
Después de eso, el desarrollador que se unió a nuestro equipo para trabajar del lado de la plataforma anterior y que configuraría la capa intermedia comenzó a hablar con el product owner y desarrollador de la plataforma anterior.
En estas sesiones se exploraba la base de datos existente y se definieron en la documentación las reglas relacionadas con estos datos, la lógica definida en el código, las excepciones causadas por los cambios en la plataforma durante los 10 años, etc.
Esto condujo a documentar qué datos deberían estar en la información que sería transformada y en la validación que podríamos ejecutar en cada línea de datos para darnos una mejor idea de cómo era el set completo de datos y dónde necesitábamos corregirlos manualmente.
Al mismo tiempo, hubo una discusión sobre cómo transferiríamos los datos y cuál era la manera más fácil de mantener los modelos en evolución por dominio en función de los datos en las diversas plataformas. Esto último fue el mayor desafío. Podíamos crear una API que realizara la validación y alguna documentación que la describa, pero cada nuevo campo agregado o regla cambiada tendría que traducirse en una implementación en ambos lados.
Como ambos sistemas usaban PHP, decidimos una colección independiente de objetos de datos que se auto-validaran en los tipos básicos link, string, float, enum, etc. Cada opción, cada entero tenía que ser correcto para que el objeto fuera válido, lo que no dejaba nada a la interpretación del desarrollador que lo usaba. Al mismo tiempo, al utilizar Composer, todo el código que usaban estas clases siempre estaría en la última versión.
Los objetos de datos definirían así cualquier entidad migrada de un sistema a otro. Pedidos, clientes, direcciones, acuerdos de facturación, etc.
Los objetos no contendrían lógica de negocio, sólo datos, y usarían nombres ubicuos, decididos por todos los involucrados en el proyecto y traducidos a términos en cada uno de sus dominios.
¿Cómo definimos entonces los términos por contexto y los traducimos en uno universal en una reunión? Teniendo un facilitador que pregunte «¿qué es eso?» y «¿por qué?» por cualquier término dicho o supuesto.
- Experto: «Un cliente siempre debe tener un pedido».
- Facilitador: «¿Qué es un cliente y qué es un pedido y por qué este cliente siempre tiene un pedido?».
- Experto: «Un pedido son productos solicitados por una persona que está registrada en nuestra tienda».
- Facilitador: «¿Esta persona pagó por sus productos? ¿Le enviaron los productos?».
- Experto: «Bueno, algunos pedidos son programados para cierta fecha, en ese caso no se pagaría ni se enviaría aún».
- Facilitador: «¿Y qué sucede si nunca pagué la factura y se pasa la fecha programada? ¿O si devolví mi pedido y nunca genero uno nuevo?».
- Experto: «Si nunca se pagó nunca fue un pedido en el viejo sistema. Y cuando se devuelve un pedido el cliente no tiene un pedido completo. Cualquiera de los dos casos harían que esa persona no sea un cliente y entonces no debería ser migrado».
En este caso sobresimplificado exponemos rápidamente reglas adicionales vinculadas a 2 términos simples que cualquier desarrollador con experiencia en Magento reconocería: Cliente y Orden. Sin embargo, dado que la definición de estos términos difiere ligeramente según el contexto (antiguo sistema, Finanzas, Magento), tendremos datos incorrectos después de la migración.
Teniendo los términos explicados en detalle con sus diferentes características comenzás a ver lo que realmente quieren decir con algo tan simple como «pedido».
Entonces, ¿por dónde se empieza?
Leé sobre los términos y comenzá a practicar un poco hablando con otros acerca de un término en su campo de experiencia. Esforzate para comprender exactamente qué quieren decir con eso y qué implica. De ésta forma vas a aprender a hacer mejores preguntas.
Para tu próximo proyecto, tratá de encontrar un pequeño grupo de expertos interesados en diversos sistemas, asegurate que tengan el tiempo para trabajar con vos en esto y empiezen a definir. Olvidate de la computadora, usá papel y lapicera y una pared en blanco con post-its y hacé que participen. Asegurate de iniciar discusiones y grabarlas para referencia futura cuando las conviertan en documentación.
Después que todo se haya puesto en papel y todos estén de acuerdo con lo que realmente significa un cliente o una factura, comiencen a construir los modelos, pero no eviten iterar sobre ellos un par de veces con los expertos mientras usan datos reales para ver si encajan. Usen datos antiguos, datos que podrían haberse almacenado antes de que se realicen cambios en el sistema actual.
Hacé que los expertos expliquen qué significan esos cambios y los reflejen tanto en su documentación como en sus modelos mientras normalizan los datos.
Déjenme saber su experiencia con esto, y no duden en contactarme (en inglés) en cualquier momento con preguntas.