Olá a todos!
Somos uma comunidade de desenvolvedores .NET no Raiffeisenbank e queremos falar sobre um conjunto de bibliotecas de infraestrutura baseadas no .NET Core para criar rapidamente microsserviços com um único ecossistema. Eles trouxeram para Open Source!
Um pouco de história
Era uma vez um grande projeto monolítico, que aos poucos se transformou em um conjunto de microsserviços (você pode ler sobre as características desse processo em ). No processo, encontramos o problema de que, ao criar novos microsserviços, muitas vezes tínhamos que copiar várias soluções de infraestrutura - como configurar log, trabalhar com banco de dados, WCF, etc. Uma equipe trabalhou neste projeto e todos já estavam acostumados com alguma abordagem estabelecida para trabalhar com infraestrutura. Portanto, separamos o código comum em um repositório separado, agrupamos as bibliotecas coletadas em pacotes Nuget e as colocamos em nosso repositório Nuget interno.
O tempo passou, o projeto foi gradualmente fragmentado e surgiu o desejo de criar novos módulos do lado do cliente em um framework JS moderno e executá-los no navegador. Começamos a migrar do WCF/SOAP para REST/HTTP, então precisávamos de novas bibliotecas para lançar rapidamente serviços baseados em AspNet WebApi. A primeira versão no .Net Framework 4.5 foi feita pelo nosso arquiteto quase de joelhos nas horas vagas, mas fora da caixa possibilitou lançar um serviço com três linhas em Program.cs que continha autorização (NTLM), logging, Swagger, IoC/DI baseado em Castle Windsor, clientes HTTP personalizados que encaminham vários cabeçalhos para fornecer registro de ponta a ponta durante todo o projeto. E tudo isso pode ser configurado diretamente no arquivo de configuração do serviço.
Porém, nem tudo correu bem: esta biblioteca revelou-se extremamente inflexível na introdução de novos módulos. Por exemplo, se você precisasse adicionar algum middleware especial, teria que criar um novo assembly e herdar da classe base que executa o serviço, o que era extremamente inconveniente. Felizmente, não houve muitos casos assim.
A era do Docker e do Kubernetes
Chegou a hora em que chegou até nós a onda do Docker e do Kubernetes, que acompanhamos de perto: afinal, foi uma grande chance de começar a avançar ainda mais nas tecnologias, no .Net Core. Isso significa que precisaremos de uma nova infraestrutura para rodar serviços: algumas bibliotecas migraram do .Net Framework para o .Net Standard e .Net Core praticamente sem alterações, algumas com pequenas melhorias. Mas acima de tudo, eu queria retrabalhar a funcionalidade associada ao lançamento de serviços no AspNet Core.
A primeira coisa que consideramos foi um conceito que eliminaria a principal desvantagem da versão anterior: a falta de flexibilidade. Portanto, optou-se por tornar todo o sistema da biblioteca o mais independente e modular possível e reunir os serviços necessários à funcionalidade como construtor.
O objetivo principal é criar uma abordagem unificada que descreva como interagir com bancos de dados, barramentos e outros serviços. Tentamos tornar as integrações rápidas e fáceis, e os desenvolvedores puderam se concentrar em escrever a lógica de negócios em vez da infraestrutura - ela já está pronta. Um repositório comum ajuda a melhorar a experiência de interação entre as equipes: quando são utilizadas infraestruturas internas muito semelhantes, é mais fácil ingressar no processo de desenvolvimento de outra equipe e trocar conhecimentos.
E por que precisamos de código aberto?
Queremos mostrar a maturidade da nossa expertise e receber feedback de qualidade: uma pessoa de fora do banco poderá trazer algo de si. Também estamos interessados no desenvolvimento de práticas para trabalhar com microsserviços e DDD em .NET na indústria, talvez alguém queira assumir certas partes do framework.
Na verdade, ViennaNET
Agora vamos dar uma olhada mais de perto. .
ViennaNET.WebApi.*
Este conjunto de bibliotecas consiste na “raiz” ViennaNET.WebApi, contendo a classe construtora para o serviço CompanyHostBuilder, e um conjunto de configuradores ViennaNET.WebApi.Configurators.*, cada um dos quais permite adicionar e configurar algumas funcionalidades ao criado. serviço. Entre os configuradores você encontra conexões para log, diagnósticos, tipos de autenticação e autorização, swagger, etc.
ViennaNET.WebApi.Runners.* também contém construtores de serviços pré-configurados. Esses pacotes permitem que você não se lembre, sempre que criar um novo serviço, de quais configuradores precisam estar conectados. No entanto, eles não limitam de forma alguma a funcionalidade do construtor de serviços.
ViennaNET.Mediador.*
Bibliotecas que permitem criar um barramento intermediário interno para comandos e solicitações dentro de um serviço. Essa abordagem permite reduzir o número de injeções DI para uma, por exemplo, em controladores. Com isso, é possível adicionar diversos decoradores às solicitações, o que unifica seu processamento e reduz a quantidade de código.
VienaNET.Validação
Um assembly contendo um conjunto de classes para criar regras de validação e sequências a partir delas. É muito conveniente para implementar a validação de domínio, pois permite descrever cada condição de negócio na forma de uma regra simples e separada.
VienaNET.Redis
Uma biblioteca com wrappers para trabalho conveniente com Redis como cache na memória.
ViennaNET.Especificações
Um assembly contendo classes que implementam o padrão Especificação.
Isso não é tudo o que está em nosso conjunto. Você pode ver o resto . Estamos planejando lançar nossas bibliotecas para trabalhar com bancos de dados em OpenSource em breve.
Obrigado pela sua atenção, aguardamos seus comentários e solicitações de pull.
Fonte: habr.com