Tech Challenge Backend API

O Desafio :triangular_flag_on_post:

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 um fake 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.

Equipe :construction_worker:

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

Pré-Requisitos :exclamation:

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

Configuração de Ambiente de Desenvolvimento Local :heavy_check_mark:

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

Configuração do Ambiente Docker/Docker Compose :heavy_check_mark:

• 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

Manual/Documentação de Funcionalidades (Swagger/Open API) :heavy_check_mark:

• 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

Workflow de Execução das APIs

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/payment
    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

Domain Storytelling :heavy_check_mark:

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

Dicionário de Linguagem Onipresente/Ubíqua

Event Storming :heavy_check_mark:

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

Domain Mapping :heavy_check_mark:

Requisitos não funcionais a serem implementados no futuro

• Testes de Integração.
• Testes de Carga/Estresse.
• Cadastro de usuário sistêmico, hoje temos apenas um usuário sistêmico, via carga do flyway.