Vue Orders System

Mini sistema de pedidos desenvolvido como teste técnico, com foco em organização de arquitetura, estado global e simulação de um fluxo real de criação de pedidos.

---

🧪 Tecnologias Utilizadas

• Vue 3 + Vite
• Pinia (gerenciamento de estado global)
• Vue Router
• Vuetify (UI e responsividade)
• SCSS
• API mockada (simulação de backend)

---

▶️ Como rodar o projeto

npm install
npm run dev

• Após iniciar, a aplicação estará disponível no ambiente local padrão do Vite.
• Login para teste: admin@test.com senha: 123456

---

🔄 Fluxo da Aplicação

Login
  ↓
Home (Catálogo)
  ↓
Adicionar itens ao carrinho
  ↓
Confirmar pedido
  ↓
OrderDetails

Esse fluxo foi pensado para simular um cenário real de e-commerce/ERP, separando claramente as etapas de seleção de itens, confirmação e visualização de pedidos.

---

🧠 Decisões Técnicas

• Pinia foi escolhido por ser o state manager oficial e recomendado no ecossistema Vue 3
• Vuetify utilizado para acelerar a construção da interface e garantir responsividade básica
• API mockada para simular chamadas assíncronas sem necessidade de backend real
• Separação clara entre:
  • Produto
  • Carrinho
  • Pedido confirmado

Essa separação melhora a organização do estado e reflete um modelo de negócio real.

---

🚀 O que faria diferente em produção

• Backend real com autenticação via JWT
• Persistência dos pedidos (ex: banco de dados)
• Testes unitários e de integração
• Controle de permissões por rota (roles)
• Paginação e filtros em listagens
• Tratamento de erros mais robusto

---

🏗️ Arquitetura da Aplicação

A aplicação segue uma arquitetura SPA (Single Page Application), com separação clara de responsabilidades entre navegação, UI e estado global.

📐 Diagrama de Arquitetura (Simplificado)

┌──────────────────────────┐
│        Vue Router        │
│ (controle de navegação)  │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│        Pages (Views)     │
│                          │
│  Login                   │
│  Home (Catálogo)         │
│  Orders (Pedidos)        │
│  OrderDetails            │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│   Layout / Components    │
│                          │
│  DefaultLayout           │
│  AppHeader               │
│  AppLoader               │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│   State Management       │
│        (Pinia)           │
│                          │
│  Auth Store              │
│  Cart Store              │
│  Orders Store            │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│    Mocked Data Layer     │
│                          │
│  Dados simulados         │
│  (sem backend real)      │
└──────────────────────────┘

---

🧩 Descrição dos Principais Blocos

Pages (Views)

Responsáveis por representar as telas da aplicação:

• Login: autenticação do usuário (mockada)
• Home: catálogo de produtos disponíveis
• Orders: lista de pedidos confirmados
• OrderDetails: detalhes de um pedido específico

Cada página consome apenas o estado necessário via Pinia, mantendo baixo acoplamento.

---

Layout & Components

• DefaultLayout: estrutura base da aplicação
• AppHeader: exibido apenas após autenticação, contendo:
  • carrinho de compras
  • preview dos itens adicionados
  • botão de logout
• Componentes reutilizáveis para loading e feedback visual

---

Gerenciamento de Estado (Pinia)

O estado global é dividido por domínio:

• Auth Store

  • controle de autenticação e logout

• Cart Store

  • mantém itens adicionados antes da confirmação do pedido

• Orders Store

  • armazena pedidos confirmados

Essa divisão reflete um modelo real de negócio, onde carrinho e pedido são entidades distintas.

---

Mocked Data Layer

Não há backend real.
Os dados são simulados diretamente nas stores, com lógica assíncrona simples para representar chamadas de API.

---

🧠 Considerações de Arquitetura

• Separação clara de responsabilidades
• Estado global centralizado e previsível
• Componentes desacoplados das regras de negócio
• Estrutura escalável para inclusão de backend real
• Fácil substituição do mock por uma API REST futuramente