Backend Assessment

Autor: Otávio Celani

Instruções de uso

Execução

Certifique-se de ter o Docker instalado na máquina

docker -v

O comando make levanta o cluster de containers em conjunto à API

make

Após o passo anterior, é possível testar a API com o comando

make test

Arquitetura

Clean Architecture

Esse projeto aplica o conceito arquitetural chamado Clean Architecture. Esse conceito é um modelo de Arquitetura Exagonal, da qual abstrai separadamente a lógica de negócio da aplicação com o objetivo de tornar os componentes reutilizáveis e extensíveis. Dessa forma, esse projeto possui a capacidade de se integrar facilmente a qualquer outro banco de dados, através da confecção simples de um adapter. Nesse projeto, foi utilizado o banco de dados MongoDB, mas também poderia utilizar qualquer outro banco de dados SQL ou NoSQL.

Microsserviços e Proxy Reverso

Foi utilizado o modelo de microsserviços, do qual os componentes da aplicação foram separados em pequenas APIs. Isso permite que o projeto realize incrementos contínuos em suas funcionalidades com o acréscimo de novos serviços, o que o torna extensível. Para tanto, foi utilizado a ferramenta Traefik na função de Proxy Reverso, do qual realiza a conexão entre as aplicações distribuídas da plataforma. A decisão pelo recurso é uma forma de assegurar a proteção do sistema e também para realizar o balanceamento de cargas.

Modelo de dados

DÉBITO AUTOMÁTICO
  ID        primitive.ObjectID
  Name      string
  Amount    string
  Frequency string
  Status    string

Rotas

Autenticação

Cria uma nova senha POST localhost:80/auth/add/:pass
Realiza a autenticação GET localhost:80/auth

Obs: o header se chama X-Auth e já consta com o token default jwt-secret pré cadastrado.

Débito automático

Registra um novo débito automático POST localhost:80/auto-debit/add
Visualiza todos os débitos cadastrados GET localhost:80/auto-debit/all
Busca por um débito automático com o ID ou Nome GET localhost:80/auto-debit/:find
Realiza uma query para visualizar todos os débitos com um determinado status GET localhost:80/auto-debit?status=:status
Aprova uma solicitação de débito PUT localhost:80/auto-debit/:id/approve
Rejeita uma solicitação de débito PUT localhost:80/auto-debit/:id/reject
Deleta uma solicitação de débito DELETE localhost:80/auto-debit/:id

Problemática da proposta

Domínio Problema

Uma instituição financeira contratou os serviços da T10 buscando maior agilidade dos dados através da metrificação de processos que, até então, não eram observados (apropriadamente). Um dos processos é a solicitação do produto débito automático de empresas parceiras. A operação é realizada manualmente e vai ser automatizada por este serviço, que vai permitir que outros serviços consumam, de forma livre, de seus eventos operacionais.

Escopo

Casos de Uso

Autenticação e acesso a plataforma
solicita uma ativação de débito automático
cancela uma solicitação de ativação
aprova uma solicitação de ativação
rejeita uma solicitação de ativação
visualiza uma solicitação

Diagrama do modelo de eventos.

Observações importantes sobre o modelo:

É uma representação do domínio exclusivamente.
Não é mandatório ser modelado usando CQRS nem event-driven.
Não é mandatório implementar o EmailServer

Requisitos

Especifica o contexto em que a aplicação será operacionalizada

Não funcionais

30 empresas parceiras
5000 usuários simultâneos
100 reqs/s

Funcionais

Tecnologias

implementação: golang | elixir | python
armazenamento: postgres | mongodb
não-mandatório broker: kafka | rabbitmq

Protocolos

pontos de entrada: http
autenticação: simple jwt

Padrões

Bonus points:

arquitetural: cqrs & hexagonal
design: ddd & solid
message bus as stream

3rd parties

O uso de bibliotecas externas é livre.

Deployment

A forma como a aplicação será disponibilizada é livre. Fica a critério do candidato, por exemplo, usar algum PaaS a fim de reduzir a complexidade bem como utilizar receitas prontas através de ferramentas de automatização e.g. ansible+dockercompose.

No entanto, é esperado bom senso na documentação caso sejam usadas soluções @ localhost.

Entrega

A Release 0.1 🚀 consiste na implementação de um servidor web que implementa os casos de uso listados acima respeitando os requisitos funcionais e não funcionais. Fica a critério do desenvolvedor como os testes serão escritos, os scripts de data migration, os schemas de entrada e saída da api e todas as outras definições que não foram listadas neste documento.

Avaliação

Critérios ordenados por ordem de peso decrescente:

Correção (correctness) da solução
- a fim de solucionar o domínio-problema
- a fim de cumprir os casos de uso
- ao implementar os requisitos especificados
Testes
Organização, documentação e clareza na estruturação do projeto
Estilo, legibilidade e simplicidade no código
Escolhas e uso de 3rd parties
Padrões de segurança

Bonus points 🏆

Teste de stress
Boas práticas na modelagem e armazenamento de dados

Eliminatórios

Copiar ou "se inspirar" em código alheio é veementemente vetado ✋

Feito 🤘

# Packages

# README