Bueno, dejémoslo en arquitecturas distribuídas, que a veces hablamos muy (demasiado) alegremente de microservicios…
La idea es hablar sobre algunos conceptos, patrones que se prestan a confusión porque muchas veces “se tocan” a nivel funcional y no queda claro si estamos uno u otro. Vamos a hablar de proxies, API Gateway, Service Mesh y Backend For Frontend.
Llamamos marker interface a una interfaz vacía. Sí, sí sin métodos ni propiedades ni nada. A pesar de que te pueda parecer una tontería tiene sus usos. Vamos hablar un poco de este patrón y sus usos y por qué es en cierta manera un anti-patrón, aunque no siempre, porque en esa vida, como todo, todo depende…
El otro día Antíoco Llanos lanzaba el siguiente tweet:
(Siempre las mismas dudas. Que dependa mi capa de negocio de EF para usar sus IDbSet o no… ¿abstraer la abstracción?)
Contesté yo con algunas sugerencias y eso derivó en otra conversación paralela, así que me parece una buena idea poner algunas pinceladas sobre como podemos abordar ese aspecto. Por supuesto y como digo siempe: no hay balas de plata y no existe la arquitectura para todo. Cada proyecto debe analizarse para valorar la arquitectura a abordar, o arquitecturas porque se pueden usar distintas en un mismo proyecto. Así, este post no tiene más pretensión que contarte algunas ideas, pero las conclusiones que saques de ellas son cosa tuya 😉
Hablando con colegas de profesión, me he dado cuenta de que muchos de ellos no terminan de comprender el patrón IoC o las ventajas que su uso comporta… Así que sin ánimo de sentar cátedra he decidido escribir este post, por si le sirve a alguien… xD