PC Example Api

Essa aplicção tem como objetivo realizar a validação de uma senha seguindo as seguintes premissas:

• Nove ou mais caracteres;
• Ao menos 1 dígito;
• Ao menos 1 letra minúscula;
• Ao menos 1 letra maiúscula;
• Ao menos 1 caractere especial: !@#$%^&*()-+
• Não considerar espaço como caracter válido;
• Não possuir caracteres repetidos dentro do conjunto.

Exemplo:

IsValid("") // false  
IsValid("aa") // false  
IsValid("ab") // false  
IsValid("AAAbbbCc") // false  
IsValid("AbTp9!foo") // false  
IsValid("AbTp9!foA") // false
IsValid("AbTp9 fok") // false
IsValid("AbTp9!fok") // true

Como executar a solução

Para possibilitar a execução da aplicação deverá seguir os passos abaixo após realizar o clone do projeto:

Obs: Deverá ser instalado o dotnet core na versão 5.0: https://dotnet.microsoft.com/download/dotnet/5.0

Possibilidade 1

1. Realizar o download do seu editor de preferencia (VS Code, Visual Studio, Rider, etc);
2. Abrir a solução do projeto no editor;
3. Executar por uma das opções (run / debug).

Possibilidade 2

1. Utilize seu prompt de comandos preferido, carregado no diretório raiz do projeto;
2. Realizar o comando dotnet run --project src/PC.Example.Api/PC.Exemple.Api.csproj para compilar a solução;

Obs: Para ambas as possibilidades, você podera acessar a documentação ou testar a aplicação através da URL http://localhost:5000/swagger.

Detalhe da solução

A solução foi dividida entre 3 projetos:

1. PC.Exemple.Api: Projeto em MVC, com as controlles que disponibilizaram os endpoints definidos na aplicação;
2. PC.Example.Domain: Projeto com o dominio de negocio da aplicação, nesse projeto teremos todas as regras de negócio (nesse caso a validação do formato da senha), entidades de negócio e interfaces para implementação das classes orquestradoras ou de acesso externo (repositórios, API externas, etc).
3. PC.Example.Test Projeto com os testes unitário para garantir as regras de negócio.

Como evolução do produto seriam criados pelo menos mais dois projetos:

1. PC.Example.Application: Contém as classes utilizada para fazer a orquestração dos fluxos funcionais;
2. PC.Example.Infra: Contém as classes auxiliares como acesso a repositório de dados, cache e aplicações externas.

Premissas assumidas

1. Na camada PC.Exemple.Api:

   • Foi descartado o uso de uma autenticação/autorização nos endpoints disponibilizados;
   • Foi descartado o uso de versionamento da API;
   • Por considerar um teste rápido não foi aplicado o padrão Mediator (apesar das classes de request serem chamadas de command);
   • Não foi aplicado na solução logs ou tracing devido ao objetivo da solução;
   • Não foi utilizado FuentValidation para validar o request para não ter nenhum tipo de validação antes do domínio.

2. Na camada PC.Exemple.Domain:

   • Foi criado uma estrutura de diretórios para exemplificar uma possível evolução do produto;
     • Models: Criado para adicionar as classes que representam o dominio de negócio;
     • Interfaces: Criado para adicionar as interfaces que apoiarão o negócio, sendo elas: Services (representando as regras de negocio), Repositories (representando os acesso a dados) e Clients (representando as integrações com outras APIs).
   • Poderia ser criados mais diretórios se existir a necessidade de criar mais classes que sejam necessárias no negócio (exemplo DTOs);
   • Essa camanda não pode ter referencias externas para manter o dominio integro.

3. Na camada PC.Exemple.Test:

   • Apesar de testar todas as camadas do projeto, os testes so foram dividos em classes, desconsiderando diretórios para agrupar as classes por camada;
   • Foi escolhido o NSubstitute para fazer o Mock sem considerar nenhum tipo de comparativo com os demais frameworks;
   • Na classe PasswordServiceTest foi utilizado os atributes Theory para exemplificar o reuso do teste com o InlineData, porem poderia ser usado de forma separada.