Repository files navigation

Uma lanchonete de bairro está em expansão devido ao seu grande sucesso. Entretanto, com essa expansão e a ausência de um sistema de controle de pedidos, o atendimento aos clientes pode tornar-se caótico e confuso. Por exemplo, imagine que um cliente faça um pedido complexo, como um hambúrguer personalizado com ingredientes específicos, acompanhado de batatas fritas e uma bebida. O atendente pode anotar o pedido em um papel e entregá-lo à cozinha, mas não há garantia de que o pedido será preparado corretamente.

Sem um sistema de controle de pedidos, pode haver confusão entre os atendentes e a cozinha, resultando em atrasos na preparação e entrega dos pedidos. Pedidos podem ser perdidos, mal interpretados ou esquecidos, levando à insatisfação dos clientes e à perda de negócios.

Em resumo, um sistema de controle de pedidos é essencial para garantir que a lanchonete possa atender os clientes de maneira eficiente, gerenciando seus pedidos e estoques de forma adequada. Sem ele, a expansão da lanchonete pode não ser bem-sucedida, resultando em clientes insatisfeitos e impactando negativamente os negócios.

Para solucionar o problema, a lanchonete irá investir em um sistema de autoatendimento de fast food, composto por uma série de dispositivos e interfaces que permitem aos clientes selecionar e fazer pedidos sem precisar interagir com um atendente, com as seguintes funcionalidades:

1. Pedido
   • Os clientes são apresentados a uma interface de seleção na qual podem optar por se identificarem via CPF, se cadastrarem com nome e e-mail, ou não se identificar. A montagem do combo segue a sequência a seguir, sendo todas as etapas opcionais:
     • Lanche
     • Acompanhamento
     • Bebida
     • Sobremesa

Em cada etapa, são exibidos o nome, descrição e preço de cada produto.

2. Pagamento

   • O sistema deverá possuir uma opção de pagamento integrada para o MVP, sendo a forma de pagamento oferecida via QRCode do Mercado Pago.
   • Nesse MVP, será realizado umfake checkout para o fluxo de pagamento, sem integração direta com o Mercado Pago.

3. Acompanhamento

   • Uma vez que o pedido é confirmado e pago, ele é enviado para a cozinha para ser preparado. Simultaneamente, deve aparecer em um monitor para o cliente acompanhar o progresso do seu pedido com as seguintes etapas:
     • Recebido
     • Em preparação
     • Pronto
     • Finalizado

4. Entrega

   • Quando o pedido estiver pronto, o sistema deverá notificar o cliente que ele está disponível para retirada. Ao ser retirado, o pedido deve ser atualizado para o status finalizado.

Além das etapas do cliente, o estabelecimento precisa de um acesso administrativo:

1. Gerenciar clientes

   • Com a identificação dos clientes, o estabelecimento pode trabalhar em campanhas promocionais.

2. Gerenciar produtos e categorias

   • Os produtos dispostos para escolha do cliente serão gerenciados pelo estabelecimento, definindo nome, categoria, preço, descrição e imagens. Para esse sistema, teremos categorias fixas:
     • Lanche
     • Acompanhamento
     • Bebida
     • Sobremesa

3. Acompanhamento de pedidos

   • Deve ser possível acompanhar os pedidos em andamento e o tempo de espera de cada pedido.

As informações dispostas no sistema de pedidos precisarão ser gerenciadas pelo estabelecimento através de um painel administrativo.

• Myller Lobo
• Jean Carlos
• Caio Isikawa
• Vanderly
• Thiago

• Maven 3
• Java 17 (Open JDK 17)
• Postgres 15
• Docker Desktop
• IntelliJ IDEA
• DBeaver SQL Client
• Postman
• k6

Clique aqui para ser redirecionado a documentação sobre clean-architecture aplicada nesse projeto

Clique aqui para ser redirecionado para a wiki de configuração do ambiente de desenvolvimento local

• A aplicação está configurada para o Flyway gerar as tabelas no PostgreSQL. Abra o DBeaver ou a ferramenta de sua escolha e verifique se as tabelas do sistema foram criadas.

Clique aqui para ser redirecionado para a wiki de configuração do ambiente Docker

Clique aqui para ser redirecionado para a wiki de documentação do banco de dados

• Dentro da pasta scripts/tests contém todos os scripts k6 para efetuar a execução os cenários de smoke-test e stress-test que foram realizados para configurar de maneira efetiva o os requests/limits da aplicação juntamente com o HPA

Clique aqui para ser redirecionado para a wiki de testes

• Para todos os endpoints privados, é necessário gerar o token via endpoint login(POST /oauth/token)

• É possível acessar o Swagger/Open API da aplicação pela seguinte URL:http://localhost:8080/swagger-ui/index.html

Segue abaixo o descritivo simplificado da jornada das APIs dentro do sistema, esses diagramas servem apenas para materializar a jornada do ClienteXTerminalxSistemaXCozinha, mas em nenhum momento substitui o detalhamento/especificação realizados no Domain Storytelling e Event Storming criados, favor utiliza-los como fonte da verdade

1 -Criação do Pedido a partir de um cliente identificado

sequenceDiagram    Cliente->>+Terminal de Autoatendimento: 1 - Informa CPF para identificação.    Terminal de Autoatendimento->>+Sistema: 2 - [GET] http://localhost:8080/api/public/v1/customers/{cpf}    Sistema-->>-Terminal de Autoatendimento: Retorna dados do cliente identificado.    Terminal de Autoatendimento-->>-Cliente: Exibir dados do cliente.    Cliente->>+Terminal de Autoatendimento: 3 - Buscar produtos para montar o pedido.    Terminal de Autoatendimento->>+Sistema: 4 - [GET] http://localhost:8080/api/public/v1/products/categories/{categoryId}    Sistema-->>-Terminal de Autoatendimento: Retorna dados dos produtos.   Terminal de Autoatendimento-->>-Cliente: Exibir dados do produto.    Cliente->>+Terminal de Autoatendimento: 5 - Escolhe produtos e realiza pedido.    Terminal de Autoatendimento->>+Sistema: 6 - [POST] http://localhost:8080/api/public/v1/orders    Sistema-->>-Terminal de Autoatendimento: Retorna dados do pedido cadastrado/recebido.    Terminal de Autoatendimento-->>-Cliente: Exibir tela de pagamento.

Observação:

• Os fluxos de 1 a 2 são opicionais.
• Não é necessário informar campo id_customer no payload do POST v1/orders uma vez que esse campo é opcional com base na escolha do usuário se identificar ou não.

3 -Pagamento do Pedido

sequenceDiagram    Fake Pagamento->>+Sistema: 1 - [POST] http://localhost:8080/api/public/v1/hook/orders/payments    Sistema-->>-Fake Pagamento: Return Status Code 200 and result SUCCESS/ERROR

4 -Acompanhamento e Preparação de Pedido na Cozinha

sequenceDiagram    Cozinha->>+Terminal interno: 1 - Buscar pedidos com status "Confirmado" para iniciar os preparos.    Terminal interno->>+Sistema: 2 - [GET] http://localhost:8080/api/private/v1/orders    Sistema-->>-Terminal interno: Retorna pedidos com status "Confirmado", "Pendente para Preparo" ou "Pronto para Retirada".    Terminal interno-->>-Cozinha: Exibir dados para cozinha iniciar os preparos.    Cozinha->>+Terminal interno: 3 - Seleciona pedido e altera status para "Em Preparação" (PREPARING)    Terminal interno->>+Sistema: 4 - [PUT] http://localhost:8080/api/private/v1/orders/status    Sistema-->>-Terminal interno: Retorna status do pedido alterado com sucesso.    Terminal interno-->>-Cozinha: Exibir mudança de status do pedido.    Cozinha->>+Terminal interno: 5 - Seleciona pedido e altera status para "Pronto para Retirada" (READY)    Terminal interno->>+Sistema: 6 - [PUT] http://localhost:8080/api/private/v1/orders/status    Sistema-->>-Terminal interno: Retorna status do pedido alterado com sucesso.    Terminal interno-->>-Cozinha: Exibir mudança de status do pedido.

5 -Finalização do pedido

sequenceDiagram    Atendente->>+Terminal interno: 1 - Seleciona pedido e altera status para "Finalizado" após retirada do cliente (FINISHED)    Terminal interno->>+Sistema: 2 - [PUT] http://localhost:8080/api/private/v1/orders/status    Sistema-->>-Terminal interno: Retorna status do pedido alterado com sucesso.    Terminal interno-->>-Atendente: Exibir mudança de status do pedido.

Clique aqui para ser redirecionado para a documentação das APIs e suas funcionalidades

Clique aqui para ser redirecionado para a documentação do domain storytelling

Clique aqui para ser redirecionado para a documentação do event storming

Clique aqui para ser redirecionado para o desenho de arquitetura e infraestrutura

• Cadastro de usuário sistêmico, hoje temos apenas um usuário sistêmico, via carga do flyway.

Clique Aqui para ser redirecionado