¡Hola a todos!
Somos una comunidad de desarrolladores .NET del Raiffeisen Bank y queremos hablar sobre un conjunto de bibliotecas de infraestructura en .NET Core para crear microservicios rápidamente con un ecosistema unificado. ¡Lo hemos lanzado como Open Source!
Un poco de historia
Una vez tuvimos un gran proyecto monolítico que se transformó gradualmente en un conjunto de microservicios (sobre las características de este proceso se puede leer en ). Durante el proceso nos enfrentamos al problema de que al crear nuevos microservicios, a menudo teníamos que copiar diversas soluciones de infraestructura, como la configuración del registro, el trabajo con bases de datos, WCF, etc. Un equipo trabajó en este proyecto, y todos ya se habían acostumbrado a un enfoque establecido para trabajar con la infraestructura. Por eso extrajimos el código común a un repositorio separado, empaquetamos las bibliotecas en paquetes NuGet y las colocamos en nuestro repositorio interno de NuGet.
Con el tiempo, el proyecto se descomponía poco a poco, surgió el deseo de crear nuevos módulos de la parte cliente en un marco Js moderno y ejecutarlos en el navegador. Comenzamos a migrar de WCF/SOAP a REST/HTTP, por lo que necesitábamos nuevas bibliotecas para iniciar rápidamente servicios basados en AspNet WebApi. La primera versión en .Net Framework 4.5 fue creada por nuestro arquitecto casi a mano en su tiempo libre, pero ya permitía iniciar un servicio con autorización (NTLM), registro, Swagger, IoC/DI basado en Castle Windsor, clientes HTTP configurados que pasan varios encabezados para garantizar el registro en todo el proyecto. Y todo esto podía configurarse adicionalmente ya en el archivo de configuración del servicio.
Sin embargo, no todo fue fácil: esta biblioteca resultó ser extremadamente rígida en cuanto a la incorporación de nuevos módulos. Por ejemplo, si se requería agregar middleware especial, era necesario crear un nuevo ensamblaje y heredar de la clase base que inicia el servicio, lo cual era muy incómodo. Afortunadamente, estos casos no fueron muy numerosos.
La era de Docker y Kubernetes
Ha llegado el momento en que la ola de Docker y Kubernetes también nos ha alcanzado, a la que hemos estado observando de cerca: era una excelente oportunidad para avanzar en las tecnologías hacia .Net Core. Esto significa que necesitaremos una nueva infraestructura para implementar servicios: parte de las bibliotecas se trasladaron de .Net Framework a .Net Standard y .Net Core prácticamente sin cambios, y otras con ligeras mejoras. Pero lo que más deseábamos era reinventar la funcionalidad relacionada con la implementación de servicios en AspNet Core.
Lo primero que se consideró fue un concepto que eliminara la principal desventaja de la versión anterior: la falta de flexibilidad. Por lo tanto, se decidió hacer que todo el sistema de bibliotecas fuera lo más independiente y modular posible y construir los servicios necesarios como un conjunto.
El objetivo principal es crear un enfoque unificado que describa cómo interactuar con bases de datos, buses y otros servicios. Nos esforzamos por hacer que las integraciones sean rápidas y sin complicaciones, para que los desarrolladores puedan concentrarse en la lógica de negocio en lugar de la infraestructura: esta ya está lista. El repositorio común ayuda a mejorar la experiencia de colaboración dentro de los equipos: cuando se utilizan infraestructuras internas muy similares, es más fácil unirse al proceso de desarrollo de otro equipo y compartir conocimientos.
¿Y por qué necesitamos el Open Source?
Queremos demostrar la madurez de nuestra experiencia y obtener retroalimentación de calidad: una persona ajena al banco podrá aportar su visión. También nos interesa el desarrollo de prácticas de trabajo con microservicios y DDD en .NET en la industria; posiblemente, alguien quiera llevar ciertas partes del marco a su entorno.
En esencia, ViennaNET
Ahora, analicemos todo en detalle. .
ViennaNET.WebApi.*
Este conjunto de bibliotecas consiste en la "raíz" de ViennaNET.WebApi, que contiene la clase constructora para el servicio CompanyHostBuilder y un conjunto de configuradores ViennaNET.WebApi.Configurators.*, cada uno de los cuales permite agregar y configurar cierta funcionalidad en el servicio creado. Entre los configuradores se pueden encontrar conexiones de registro, diagnóstico, tipos de autenticación y autorización, swagger, etc.
Aquí, ViennaNET.WebApi.Runners.* contiene constructores de servicios preconfigurados. Estos paquetes evitan que tengas que recordar qué configuradores necesitas cada vez que creas un nuevo servicio. Además, no limitan en absoluto la funcionalidad del constructor de servicios.
ViennaNET.Mediator.*
Bibliotecas que permiten crear un bus intermedio interno para comandos y consultas dentro del servicio. Este enfoque reduce la cantidad de inyecciones DI a una, por ejemplo, en los controladores. Gracias a esto, se pueden añadir diversos decoradores a las consultas, lo que unifica su procesamiento y reduce la cantidad de código.
ViennaNET.Validation
Ensamblaje que contiene un conjunto de clases para crear reglas y secuencias de validación. Muy útil para la implementación de validaciones de dominio, ya que permite describir cada condición comercial como una regla simple y separada.
ViennaNET.Redis
Biblioteca con envolturas para un uso conveniente de Redis como caché en memoria.
ViennaNET.Specifications
Ensamblaje que contiene clases que implementan el patrón de 'Especificación'.
Esto no es todo lo que hay en nuestro conjunto. El resto se puede ver . Pronto se planea lanzar nuestras bibliotecas para trabajar con bases de datos en OpenSource.
Gracias por su atención, esperamos sus comentarios y pull requests.
Fuente: habr.com
