Últimamente se está poniendo de moda the Microservices, aunque al parecer antes era OSGi. Hasta la fecha he estado en varios proyectos los cuales son micro servicios y tengo puesto el ojo en OSGi para una aplicación Desktop (jar ejecutable), la cual claramente tendría varios módulos que añadirían funcionalidades adicionales.
Qué me decíis, ¿cual os parece mejor o peor?
Para los que no han oído hablar de ni uno, ni de otro:
Hombre pues los microservicios están enfocados al backend y escalabilidad, no tiene mucho sentido hacer una app desktop con una arquitectura de microservicios y todo lo que eso conlleva y te surgen cosas cómo el discovery, qué haces cuando un servicio se para, o si quiera cómo los lanzo xD
OSGi sirve realmente para una arquitectura de plugins (eclipse por ejemplo lo usaba, en las ultimas versiones no sé si lo seguirá usando) que realmente encaja mucho en una aplicación desktop, lo malo es que tienes que diseñar el core bastante bien y proveer un buen sdk para que se desarrollen plugins para la app. Suelen ser bastante robustas.
Yo lo he usado con una app de android bastante grande y que por cojones tenía que llevarlo y la verdad, no lo usaría si no fuera estrictamente necesario (es decir, la app va a llevar plugins si o si). Puedes mirar el apache felix container que es bastante sencillo de usar. Aquí tienes un hello world que hice en OSGi para que no se me olvidara su uso hace ya unos años, obviamente es mejorable xD
#2 Mi intención es que la aplicación (el core) tenga una funcionalidad básica y para añadirle más funcionalidad sea mediante plugins que mejore el core.
Imagina que el core tiene 2 funciones: sumar y restar, devolviendo el resultado.
Ahora añado nuevo módulo que hace un println al ejecutar/finalizar un método.
Aunque no es lo que tengo pensado hacer (tengo mucha ambición la verdad xD), sería la misma situación.
El otro día estuve viendo una conferencia cojonuda de Robert C. Martin, precisamente por el post que pusiste por FEDA /dev/ y por mi experiencia personal en un proyecto que estoy trabajando, sobre lo que el considera la mejor arquitectura posible o arquitectura limpia o arquitectura "plugin".
Consiste en utilizar los conceptos de arquitectura orientada a objetos de los 90 e ir un paso más allá utilizando también el concepto de MVC.
La arquitectura se basa básicamente en una serie de componentes:
Entity, objeto de negocio independiente de la aplicación, por ejemplo, Empleado, Carro de compra, Producto, etc.
Iteractor/Use Case, objeto de negocio dependiente de la aplicación, es una patrón command que representa una acción, por debajo utiliza las diversas entities como si de un director de orquesta se tratara, algunos ejemplos son CrearEmpleado, GuardarCarroDeCompra, EditarProducto.
Boundary, son interfaces de entrada y salida que son implementadas desde fuera del core de la aplicación, para comunicarse con él.
Principio de inversión de dependencia, los elementos de más abajo no pueden comunicarse con los de arriba, es decir, un entity, jamás tiene que saber nada de un Interactor.
Request model, estructura de datos básica con la información necesaria que se pasa desde un boundary de entrada -> Interator -> 1+ entities.
Response model, estructura de datos básica como respuesta creada por los 1+ entities -> Interactor -> boundary de salida.
Los boundaries tienen que especificar con su interfaz cómo son esos datos independientemente de la implementación.
Controller, implementa boundary de entrada, es decir, se encargaría por ejemplo de recoger datos de teclado o información de los socket y comunicarlo con el request model al interactor.
Presenter, implementa boundary de salida, es decir, se encargaría de recibir datos de la aplicación a través del response model para mostrar contenido por pantalla, o guardar a un fichero.
ViewModel, esto sería por ejemplo, una página web con todos los tags sin rellenar, como las plantillas de Django, Node.js, etc.
View, siguiendo el ejemplo anterior, sería la página web estática con toda la información.
Gateway, sería un entity con información específica para comunicarse con la base de datos que no dependa de la aplicación, aquí se pondría los DAOs con etiquetas o atributos, objetos tontos con información de las tablas, también se usaría para abstraerse de los framework.
Robert C. Martin sugiere que el controller, presenter y gateway sean plugins totalmente independientes de tu aplicación, si te haces un presenter para una página web, podrias hacer otro para una aplicación de escritorio sin tocar nada del core. Ciertamente, parece todo muy laborioso pero si uno se pone, se monta el esqueleto básico le sirve para todas las aplicaciones futuras, que puedas tener un montón de código y poder mantenerlo sin frustraciones.
No obstante, recomiendo que te veas el video completo de la conferencia, lo que he explicado no hace justicia a lo claro que lo explica Martin.
#1 Los microservicios son un arma de doble filo aunque yo me inclino por estos en arquitecturas grandes. Por ejemplo, sector retail. Donde los equipos de desarrollo pueden atacar a cosas totalmente independientes y llevar a cabo un desarrollo sin dependencias y autoorganizado.
#4 El esquema que has puesto cómo estaría enfocado? (no he visto el vídeo jeje) Si te pongo el siguiente ejemplo:
#5 Si lo he entendido bien, exactamente, tendrías todos esos esquemas como interactors/casos de uso independientes, ahora bien dices, necesitas relacionar la información que recibes entre controller y presenter de alguna forma, mirando por Google ponen una solución de los más interesante, denominada patrón Repository, que consiste en guardar la información necesaria abajo, en las entities como si de almacenes se tratarán, que luego, podrás consultar en el siguiente caso de uso.
Enlaces con información relevante:
https://medium.com/@stephanhoekstra/clean-architecture-in-net-8eed6c224c50#.aezzj1i207
http://martinfowler.com/eaaCatalog/repository.html
#6 Vale, si. Esto parece una tendencia porque estamos a punto de empezar a implantar esta idea en el curro.
Lo que llamas almacenes los estamos pensando mediante redis... a ver que tal va
