Olá a todos!
Nós somos uma comunidade de desenvolvedores .NET do Raiffeisenbank e queremos apresentar um conjunto de bibliotecas de infraestrutura em .NET Core para a criação rápida de microsserviços com um ecossistema unificado. Tornamos isso Open Source!
Um pouco de história
Um dia, tivemos um grande projeto monolítico que gradualmente se transformou em um conjunto de microsserviços (sobre os detalhes desse processo, você pode ler em ). Durante esse processo, enfrentamos o problema de que, ao criar novos microsserviços, frequentemente precisávamos copiar várias soluções de infraestrutura - como configurações de logging, interação com o banco de dados, WCF, etc. Uma única equipe trabalhou neste projeto, e todos já estavam acostumados a uma abordagem estabelecida de trabalho com infraestrutura. Portanto, destacamos o código comum em um repositório separado, empacotamos as bibliotecas em pacotes Nuget e as colocamos em nosso repositório Nuget interno.
O tempo passou, o projeto foi se fragmentando, surgiu o desejo de criar novos módulos para a parte cliente usando um framework Js moderno e executá-los no navegador. Começamos a transitar de WCF/SOAP para REST/HTTP, portanto precisávamos de novas bibliotecas para o lançamento rápido de serviços baseados em AspNet WebApi. A primeira versão no .Net Framework 4.5 foi feita pelo nosso arquiteto praticamente em seu tempo livre, mas já permitia iniciar um serviço com três linhas no Program.cs, contendo autenticação (NTLM), logging, Swagger, IoC/DI baseado em Castle Windsor, clientes HTTP configurados que passavam vários cabeçalhos para garantir o logging abrangente em todo o projeto. E tudo isso podia ser configurado adicionalmente diretamente no arquivo de configuração do serviço.
No entanto, nem tudo foi tranquilo: essa biblioteca resultou ser extremamente inflexível em termos de incorporação de novos módulos. Por exemplo, se era necessário adicionar algum middleware especial, era preciso criar um novoassembly e herdar da classe base que iniciava o serviço, o que era bastante inconveniente. Felizmente, tais casos não foram muitos.
A era do Docker e Kubernetes
Chegou a hora em que também fomos impactados pela onda do Docker e Kubernetes, que acompanhamos de perto: era uma ótima oportunidade para avançar nas tecnologias, adotando o .Net Core. Isso significa que precisaremos de uma nova infraestrutura para o lançamento de serviços: algumas bibliotecas foram migradas do .Net Framework para o .Net Standard e .Net Core praticamente sem alterações, enquanto outras com pequenas melhorias. Mas o que mais queríamos era reformular a funcionalidade relacionada ao lançamento de serviços no AspNet Core.
O primeiro passo foi considerar um conceito que eliminasse a principal desvantagem da versão anterior: a falta de flexibilidade. Por isso, decidimos tornar todo o sistema de bibliotecas o mais independente e modular possível, e montar os serviços necessários como se fosse um quebra-cabeça.
O objetivo principal é criar uma abordagem unificada que descreva como interagir com bancos de dados, barramentos e outros serviços. Nos esforçamos para que as integrações fossem rápidas e indolores, permitindo que os desenvolvedores se concentrassem na escrita da lógica de negócios, em vez da infraestrutura – esta já está pronta. O repositório comum ajuda a melhorar a experiência de interação dentro das equipes: quando estruturas internas muito semelhantes são usadas, é mais fácil se incorporar ao processo de desenvolvimento de outra equipe e trocar experiências.
E por que precisamos de Open Source?
Queremos demonstrar a maturidade da nossa expertise e obter feedback de qualidade: uma pessoa fora do banco poderá trazer novas contribuições. Também nos interessa o desenvolvimento de práticas de trabalho com microsserviços e DDD no .NET na indústria, pois talvez alguém queira levar certas partes do framework consigo.
A propósito, ViennaNET
Agora vamos analisar tudo em detalhes. .
ViennaNET.WebApi.*
Esse conjunto de bibliotecas consiste na "raiz" ViennaNET.WebApi, que contém a classe construtora para o serviço CompanyHostBuilder, e um conjunto de configuradores ViennaNET.WebApi.Configurators.*, cada um permitindo adicionar e configurar uma determinada funcionalidade no serviço criado. Entre os configuradores, pode-se encontrar integração de logging, diagnósticos, tipos de autenticação e autorização, swagger, etc.
Aqui, ViennaNET.WebApi.Runners.* contém construtores de serviços pré-configurados. Esses pacotes permitem que você não precise se lembrar sempre, ao criar um novo serviço, quais configuradores devem ser conectados. Ao mesmo tempo, eles não limitam a funcionalidade do construtor de serviços.
ViennaNET.Mediator.*
Bibliotecas que permitem criar um barramento interno para comandos e consultas dentro do serviço. Essa abordagem reduz o número de injeções de DI para uma única, por exemplo, nos controladores. Com isso, é possível adicionar diferentes decoradores às consultas, o que uniformiza seu processamento e reduz a quantidade de código.
ViennaNET.Validation
Uma assembly que contém um conjunto de classes para criar regras de validação e sequências a partir delas. Muito conveniente para a implementação de validações de domínio, pois permite descrever cada condição de negócio como uma regra simples e separada.
ViennaNET.Redis
Uma biblioteca com wrappers para facilitar o trabalho com Redis como cache em memória.
ViennaNET.Specifications
Uma assembly que contém classes que implementam o padrão 'Especificação'.
Isso não é tudo o que temos em nosso conjunto. O restante pode ser visto . Em breve, planejamos lançar nossas bibliotecas para trabalhar com bancos de dados como OpenSource.
Obrigado pela atenção, aguardamos seus comentários e pull requests.
Fonte: habr.com
