└── README.md


/README.md:
--------------------------------------------------------------------------------
 1 | # Backend Challenge - Rits Tecnologia
 2 | Desafio para desenvolvedor backend para Rits Tecnologia.
 3 | 
 4 | Por esse desafio, o desenvolvedor deverá mostrar ser capaz de desenvolver uma API RESTFul, para criar pedidos de uma lanchonete, e um painel administrativo para cadastrar os produtos e gerenciar os pedidos.
 5 | 
 6 | ## Instruções para entrega
 7 | - Seu código deverá ser versionado com Git e hospedado no GitHub;
 8 | - Crie um README.md explicando como solucionou o problema, como poderemos executar e outros pontos que achar necessário;
 9 | - Envie um e-mail para lucassoares@rits.com.br com o assunto "Desafio desenvolvedor Rits".
10 | 
11 | ## Sobre o problema
12 | O Sistema deverá contemplar os módulos: __Cliente__, __Produto__ e __Pedido__. Um __Pedido__ pertence a um __Cliente__ e um __Pedido__ contém vários __Produtos__.
13 | 
14 | A API será utilizada para o _client_ que irá realizar os pedidos. Nesse sentido, ela deverá conter _endpoints_ para que um __Cliente__ possa se cadastrar. Além de `criar`, `listar`, `ver` e `excluir` __Pedidos__ de um __Cliente__ específico. Obs.: Para evitar autenticação, o id do __Cliente__ pode ser usado como parâmetro para realizar essas ações.
15 | 
16 | O painel administrativo deve conter uma autenticação básica. E através dele deverá ser possível `listar` __Clientes__ e `listar` __Pedidos__, além de poder gerenciar os __Produtos__ da lanchonete, com as ações `CRUD`.
17 | 
18 | Os campos para cada entidade serão:
19 | - Cliente: `nome`, `email`, `telefone` e `endereço`;
20 | - Produto: `nome` e `preço`;
21 | - Pedido: `código do cliente`, `código do produto`, `data de criação` e `status do pedido`.
22 | 
23 | O __Pedido__ poderá conter os `status`: `Pendente`, `Em preparo`, `Em entrega`, `Entregue` e `Cancelado`.
24 | 
25 | ## Requisitos
26 | - Não poderá existir mais de um __Cliente__ com o mesmo `email` ou `telefone`;
27 | - Todos os dados deverão ser validados;
28 | - Um __Cliente__ não pode excluir um __Pedido__ criado por outro __Cliente__.
29 | 
30 | ## Diferenciais
31 | - Testes unitários;
32 | - Estrutura pra subir a aplicação com `DockerFile` ou `docker-compose`;
33 | - Um _bot_ no Telegram, que recebe quando um __Pedido__ é criado ou cancelado;
34 | - Aplicação de padrões de projeto como `Repository`, `Service Layer` ou `Command Pattern`;
35 | - Uma notificação em tempo real de quando um __Pedido__ for criado ou cancelado.
36 | 
37 | ## Critérios de avaliação
38 | - Profundidade de conhecimento do framework escolhido;
39 | - Organização do código;
40 | - Fidelidade aos requisitos;
41 | 


--------------------------------------------------------------------------------