O TryLog é uma Central de Erros, responsável por centralizar os registros de erros de várias aplicações. Ele têm as principais funcionalidades das Centrais de Erro presentes no mercado, além de possuir características pertinentes ao Banco Itaú, conforme nossa interpretação do desafio proposto pela Codenation.

A inspiração para o desenvolvimento do TryLog foi atender ambientes complexos (vários serviços, diversas aplicações com diferentes camadas). Tais ambientes são comuns em grandes empresas como o Banco Itaú, por isso, imaginamos possíveis cenários em que o TryLog poderia ser utilizado, como por exemplo: identificar falhas, intermitências e gargalos. Estas informações contribuiriam na evolução das aplicações, tanto para desenvolvimento como no gerenciamento das mesmas.

Este projeto deve servir para capturar erros vindos de qualquer aplicação. Para permitir que isso aconteça, disponibilizaremos endpoints REST para tratar as mensagens de erro capturadas em diversas plataformas, como: mobile, site e o próprio backend desta aplicação. Tentaremos seguir o mais próximo da teoria REST apresentada por Roy Fielding.

Como se trata de um projeto vinculado a Codenation/Itaú e possui um intuito de aprendizado/demonstração de conhecimento, nos propomos a descrever com detalhes os conceitos que vamos utilizar, mostrando como os entendemos.

Decidimos separar as camadas de projeto, tendo como orientação o modelo Clean Architecture, de Bob Martin, mas usado aqui na visão de Steve Smith. Info: Microsoft Docs.

Através desta modelo arquitetural, esperamos melhorar a forma como o projeto é separado e compreendido. Tendo também vantagens como uso de injeção de dependência, fazendo a inversão do controle e viabilizando testes automatizados (unitários a princípio).

Também nos serviu de base o material apresentado no livro Asp.NET Core Architecture e-book, disponível em sítio Microsoft.

Esta camada é responsável por armazenar as abstrações do nosso universo. Por exemplo, o que é um log de erro será representado aqui por uma classe.

Nesta camada você vai encontrar os seguintes itens:

• Entidades
• Interfaces

São itens desta camada, aqueles relativos à:

• Conexão com banco de dados
• Tipos representando o banco de dados
• Implementações de acesso a dados (das Interfaces definidas no Core)
• Serviços específicos de infraestrutura

Embora não esteja descrita nos materiais de arquitetura mencionados, achamos por bem adicionar uma camada para isolar as funcionalidades do sistema. Nela você vai encontrar:

• Regras de negócio
• Funcionalidades descritas em casos de uso (ViewModels)

Esta camada será responsável por receber as requisições dos clientes e endereçá-las. Vamos tratar aqui:

• Autenticação e autorização (JWT)
• Controladoras, Rotas e Bindings
• Injeção de dependência
• Ativação de serviços que afetam o pipeline HTTP

Para adicionar o EF Core, juntamente com os demais utilitários, usamos o seguintes comandos:

//Adiciona na EF na camada de infraestrurura
dotnet add .\src\Infraestructure\ package Microsoft.EntityFrameworkCore.SqlServer
dotnet tool install --global dotnet-ef
dotnet add .\src\Infraestructure\ package Microsoft.EntityFrameworkCore.Design
dotnet add .\src\Infraestructure\ package Microsoft.EntityFrameworkCore.Tools

//Adiciona na camada de webapi para fins de injeção de dependência
dotnet add .\src\WebApi\ package Microsoft.EntityFrameworkCore.SqlServer
dotnet add .\src\WebApi\ package Microsoft.EntityFrameworkCore.InMemory

Uma condição verifica quando o Environment é igual a Development e trata de registrar no container de dependência o provider de InMemory para o EF, ou, se Production, registra o SqlServer.

Por fim uma camada para separar os testes será utilizada.

Luiz Nogueira	Maira Barbosa	Moyses Souza	Rafael Pinto	Vinicius Santos

Front-end	Swagger