Lo justo y lo estándar

Desde hace unos meses, he estado envuelto en algunos proyectos, en los que he intentado dar un enfoque basado en patrones y estándares, para facilitar y simplificar los problemas. Solo que, hay patrones y sistemas, o frameworks, que son algo incompatibles entre sí.

Por ejemplo, el uso de un sistema BPM, puede ser compatible con un sistema REST como Ruby on Rails, mientras se mantenga la idea de REST… en cambio, si se modifica por intentar realizar un poco interoperatibilidad entre otros sistemas, a los cuales no se les quiere cambiar mucho la forma… se convierte en un infierno.

Al final, lo mejor, es mirar la piezas con las que queremos contar, por ser afines a los resultados que queremos obtener y, emplear única y exclusivamente, los patrones que se puedan ajustar bien a esas piezas.

En este caso, por ejemplo, Ruby on Rails, combina bien con sistemas BPM que sean REST, e incluso con bases de datos que sean REST, pero le quita características bastante deseables que sí tiene otro patrón como ActiveRecord, ante lo cual, se establece un sistema de preferencias y prioridades… ¿REST o ActiveRecord?… como es lógico, optando por ActiveRecord, desaparece BPM como tal, ya que ActiveRecord está hecho para su acceso directo a base de datos.

Pero al final, la base de datos, bien mirada, termina siendo nuestro sistema BPM y, con ayuda de procedimientos almacenados, triggers, usuarios y demás… es un sistema, no tan potente como otros, pero sí lo suficiente como para cumplir con las especificaciones básicas.

Bueno, al final, me doy cuenta de que, al igual que cuando se programa, se debe de decidir bien la estructura, los elementos a emplear, la forma y demás… cuando se desarrolla, se ha de tener especial cuidado con las metodologías, patrones de diseño y estándares, puesto que hay que comprobar que coordinen bien entre sí.