404 Not Found

404 Not Found


nginx

Exercício Prático Completo: Design do Projeto OrderFlow

Design de projeto é a planta baixa do desenvolvimento — requisitos determinam a direção, seleção de tecnologia determina a abordagem e design determina a arquitetura. Preparação é metade da batalha.

1. O Que Você Vai Aprender


2. Uma História Real de um Gerente de Produto

(1) Dor: O Gap Entre Requisitos e Código

Charlie abordou Alice com um documento de requisitos vago: "Precisamos de um sistema de gerenciamento de pedidos de e-commerce." Alice perguntou: "Quais funcionalidades ele precisa? Quais são os diferentes papéis de usuário? Quais atributos os produtos têm? Como pedidos e pagamentos estão ligados?" Charlie não conseguiu explicar claramente, então Alice teve que adivinhar com base em sua experiência. Como resultado, após duas semanas de desenvolvimento, Charlie disse: "Isso não é o que eu queria."

(2) Soluções de Design de Sistema

Design primeiro, depois desenvolvimento — Análise de Requisitos → Seleção de Tecnologia → Design do Banco de Dados → Especificações de API. Confirmar cada etapa com Charlie:

100%
graph TD
    A["Análise de<br/>Requisitos"] --> B["Seleção de<br/>Stack Tecnológica"]
    B --> C["Design do<br/>Banco de Dados"]
    C --> D["Especificação<br/>de API"]
    D --> E["Plano de<br/>Desenvolvimento"]

(3) Resultado

Depois que Alice e Charlie passaram dois dias finalizando o design do sistema, a direção de desenvolvimento ficou clara e entregaram um MVP que atendeu às expectativas em três semanas. Charlie disse: "Era exatamente o que eu queria da primeira vez."


3. Análise de Requisitos

(1) Quatro Módulos Principais

Módulo Funcionalidades Centrais Papéis de Usuário
Gerenciamento de Usuários Registro, Login, Informações Pessoais, Gerenciamento de Papéis TODOS
Gerenciamento de Produtos CRUD, Categorias, Busca, Gerenciamento de Estoque ADMIN
Gerenciamento de Pedidos Fazer Pedidos, Ver Pedidos, Cancelar Pedidos, Cancelamento Automático por Timeout CUSTOMER / ADMIN
Gerenciamento de Pagamentos Iniciar Pagamentos, Tratamento de Callbacks, Reembolsos CUSTOMER / ADMIN

(2) Matriz de Papel-Permissão

Funcionalidade CUSTOMER ADMIN
Cadastrar / Fazer Login
Navegar Produtos
Buscar Produtos
Criar / Gerenciar Produtos
Fazer Pedido
Ver Seus Pedidos
Ver Todos os Pedidos
Cancelar Seu Pedido
Cancelar qualquer pedido
Iniciar Pagamento
Processar Reembolso

(1) ▶ Exemplo: User Story

TEXT
Como CUSTOMER, eu quero:
  - Navegar e buscar produtos
  - Adicionar produtos ao carrinho (futuro)
  - Fazer um pedido com múltiplos itens
  - Ver meu histórico de pedidos
  - Cancelar um pedido não pago em até 30 minutos
  - Pagar por um pedido
  - Ver status do pagamento

Como ADMIN, eu quero:
  - Gerenciar produtos (CRUD)
  - Ver todos os pedidos
  - Cancelar qualquer pedido
  - Processar reembolsos
  - Ver estatísticas de negócio

Saída:

TEXT
Execução bem-sucedida

4. Seleção de Tecnologia

(1) Matriz de Decisão de Seleção de Produto

Ponto de Decisão Opção A Opção B Escolha Motivo
Frameworks Web WebMVC WebFlux WebMVC Primariamente CRUD, concorrência < 5.000; WebMVC é mais simples
Método de Autenticação Session JWT JWT Arquitetura de microsserviços, implantação multi-instância, autenticação stateless
Estratégia de Cache Caffeine Local Redis Distribuído L1 Caffeine + L2 Redis Acesso local rápido a dados quentes; cache distribuído garante consistência
Banco de Dados PostgreSQL MySQL MySQL Familiar para a equipe, ecossistema maduro
Acesso ao Banco JPA MyBatis JPA Mapeamento de objetos mais natural, reduz necessidade de escrever SQL
Documentação de API SpringDoc Manual SpringDoc Gerar automaticamente documentação OpenAPI

(2) Visão Geral do Stack Tecnológico

Camada Tecnologia Versão
Linguagem Java 17 LTS
Framework Spring Boot 3.2.x
Web Spring MVC 6.x
Segurança Spring Security + JWT 6.x
Banco de Dados MySQL 8.0
ORM Spring Data JPA 3.x
Cache Caffeine + Redis 3.x / 7.x
Validação Bean Validation 3.x
Testes JUnit 5 + Mockito + TestContainers 5.x
Documentação SpringDoc OpenAPI 2.x
Monitoramento Actuator + Micrometer 3.x
Implantação Docker + Kubernetes 24.x / 1.28

5. Design do Banco de Dados

(1) Diagrama ER Completo

100%
erDiagram
    USER ||--o{ ORDER : "faz"
    PRODUCT ||--o{ ORDER_ITEM : "incluído em"
    ORDER ||--o{ ORDER_ITEM : "contém"
    ORDER ||--o| PAYMENT : "tem"

    USER {
        bigint id PK
        varchar username UK
        varchar email UK
        varchar password_hash
        varchar role
        timestamp created_at
        timestamp updated_at
    }
    PRODUCT {
        bigint id PK
        varchar name
        varchar sku UK
        decimal price
        int stock
        varchar category
        tinyint status
        timestamp created_at
        timestamp updated_at
    }
    ORDER {
        bigint id PK
        bigint user_id FK
        varchar order_number UK
        varchar status
        decimal total_amount
        timestamp created_at
        timestamp updated_at
    }
    ORDER_ITEM {
        bigint id PK
        bigint order_id FK
        bigint product_id FK
        int quantity
        decimal unit_price
        decimal subtotal
    }
    PAYMENT {
        bigint id PK
        bigint order_id FK
        varchar transaction_id UK
        varchar method
        varchar status
        decimal amount
        timestamp paid_at
        timestamp created_at
    }

(1) ▶ Exemplo: Statement DDL de criação de tabela

SQL
CREATE TABLE users (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL UNIQUE,
    email VARCHAR(100) NOT NULL UNIQUE,
    password_hash VARCHAR(255) NOT NULL,
    role VARCHAR(20) NOT NULL DEFAULT 'CUSTOMER',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

CREATE TABLE products (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    sku VARCHAR(20) NOT NULL UNIQUE,
    price DECIMAL(10,2) NOT NULL,
    stock INT NOT NULL DEFAULT 0,
    category VARCHAR(50),
    status TINYINT NOT NULL DEFAULT 1,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_product_name (name),
    INDEX idx_product_category (category)
);

CREATE TABLE orders (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    order_number VARCHAR(20) NOT NULL UNIQUE,
    status VARCHAR(20) NOT NULL DEFAULT 'PENDING',
    total_amount DECIMAL(10,2) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_order_user (user_id),
    INDEX idx_order_status_created (status, created_at DESC),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

CREATE TABLE order_items (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT NOT NULL,
    unit_price DECIMAL(10,2) NOT NULL,
    subtotal DECIMAL(10,2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(id),
    FOREIGN KEY (product_id) REFERENCES products(id)
);

CREATE TABLE payments (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_id BIGINT NOT NULL UNIQUE,
    transaction_id VARCHAR(50) UNIQUE,
    method VARCHAR(20) NOT NULL,
    status VARCHAR(20) NOT NULL DEFAULT 'PENDING',
    amount DECIMAL(10,2) NOT NULL,
    paid_at TIMESTAMP NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (order_id) REFERENCES orders(id)
);

Saída:

TEXT
CREATE TABLE

6. Design de Especificação de API

(1) Especificações RESTful API

(1) ▶ Exemplo: Lista de Endpoints da API

Módulo Método URI Descrição Permissões
Auth POST /api/v1/auth/login Login Público
Auth POST /api/v1/auth/register Registrar Público
Produto GET /api/v1/products Lista de Produtos Público
Produto GET /api/v1/products/{id} Detalhes do Produto Público
Produto POST /api/v1/products Criar Produto ADMIN
Produto PUT /api/v1/products/{id} Atualizar Produto ADMIN
Produto DELETE /api/v1/products/{id} Excluir Produto ADMIN
Pedido POST /api/v1/orders Fazer Pedido CUSTOMER+
Pedido GET /api/v1/orders Meus Pedidos CUSTOMER+
Pedido GET /api/v1/orders/{id} Detalhes do Pedido Owner/ADMIN
Pedido GET /api/v1/admin/orders Todos os Pedidos ADMIN
Pedido DELETE /api/v1/orders/{id} Cancelar Pedido Owner/ADMIN
Pagamento POST /api/v1/payments Iniciar Pagamento CUSTOMER+
Pagamento POST /api/v1/payments/callback Callback de Pagamento Interno

(2) ▶ Exemplo: Formato de Resposta Padronizado

JAVA
// Resposta de sucesso
public record ApiResponse<T>(
    int code,
    String message,
    T data,
    Instant timestamp
) {
    public static <T> ApiResponse<T> success(T data) {
        return new ApiResponse<>(200, "OK", data, Instant.now());
    }
    public static <T> ApiResponse<T> created(T data) {
        return new ApiResponse<>(201, "Created", data, Instant.now());
    }
}

// Resposta paginada
public record PagedResponse<T>(
    List<T> content,
    int page,
    int size,
    long totalElements,
    int totalPages
) {}

Saída:

TEXT
// Execução bem-sucedida

(3) ▶ Exemplo: Parâmetros de Paginação e Ordenação

BASH
# Listar produtos com paginação, ordenação e filtragem
GET /api/v1/products?page=0&size=20&sort=price,desc&category=electronics&minPrice=100&maxPrice=999

Saída:

TEXT
// Comando executado com sucesso

7. Plano de Desenvolvimento e Atribuições de Módulos

(1) ▶ Exemplo: Plano de Iteração

Sprint Iteração Objetivo Entregáveis
Sprint 1 Semanas 1-2 Framework Básico Estrutura do Projeto + Autenticação + CRUD de Produtos
Sprint 2 Semanas 3-4 Negócio Central Módulo de Pedidos + Transações + Validação + Exceções
Sprint 3 Semanas 5-6 Funcionalidades Avançadas Cache + Tarefas Agendadas + Notificações Assíncronas
Sprint 4 Semanas 7-8 Operações e Implantação Docker + K8s + Monitoramento e Alertas

8. Exemplo Completo: Documento de Design do Projeto OrderFlow

MARKDOWN
# Documento de Design do Sistema OrderFlow

## 1. Requisitos de Negócio
- Sistema de gerenciamento de pedidos de e-commerce
- 4 módulos: Usuário, Produto, Pedido, Pagamento
- 2 papéis: CUSTOMER, ADMIN
- Expectativa: 10.000 DAU, 1.000 pedidos/dia

## 2. Stack Tecnológico
- Java 17 + Spring Boot 3.2.x
- MySQL 8.0 + Spring Data JPA
- Redis 7 + Caffeine (cache de dois níveis)
- Spring Security + JWT (OAuth2 Resource Server)
- Implantação Docker + Kubernetes

## 3. Design do Banco de Dados
- 5 tabelas: users, products, orders, order_items, payments
- Índices em colunas de consulta de alta frequência

## 4. Especificação de API
- API RESTful com versionamento (/api/v1/)
- Autenticação JWT Bearer
- Formato de resposta unificado: ApiResponse<T>
- Paginação: parâmetros page, size, sort

## 5. Requisitos Não Funcionais
- Latência P99 < 100ms
- Taxa de erro < 0,1%
- Disponibilidade > 99,9%
- Cobertura de testes automatizados > 80%

❓ Perguntas Frequentes

P Por que escolher WebMVC em vez de WebFlux?
R O OrderFlow envolve primariamente operações CRUD, com uma concorrência esperada < 5.000 QPS; WebMVC é mais simples e maduro. WebFlux é adequado para cenários intensivos em E/S, de alta concorrência e streaming em tempo real; usá-lo para um projeto CRUD realmente aumentaria a complexidade.
P Por que usar cache de dois níveis em vez de apenas Redis?
R L1 Caffeine é o mais rápido (nível de nanosegundo), enquanto L2 Redis garante consistência entre múltiplas instâncias. Dados quentes acertam o cache local, reduzindo o overhead de rede do Redis.
P O versionamento de API deve usar caminhos de URL ou headers?
R Versionamento por caminho de URL (/api/v1/) é mais intuitivo, mais fácil de testar e mais amigável para SEO. Versionamento por header é mais RESTful mas mais difícil de depurar. Na prática, recomendamos versionamento por URL.
P Como é garantida a segurança dos callbacks de pagamento?
R 1) A URL de callback é acessível apenas pela rede interna; 2) A assinatura do callback é verificada; 3) Processamento idempotente é usado (callbacks repetidos não resultam em cobranças duplicadas); 4) Logs de callback são registrados para fins de conciliação.
P Como lidar com soft deletes e hard deletes no design do banco de dados?
R Use soft deletes (status=CANCELLED) para dados de negócio críticos (pedidos, pagamentos) para preservar trilhas de auditoria. Dados auxiliares (produtos de teste) podem ser hard deleted. Soft deletes requerem filtragem dos registros excluídos em todas as consultas.
P Quão detalhados devem ser os documentos de design de projeto?
R Devem ser detalhados o suficiente para que novos membros da equipe entendam o panorama geral do sistema. Devem incluir: requisitos de negócio, escolhas de tecnologia e a lógica por trás delas, design do banco de dados, especificações de API e requisitos não funcionais. Não há necessidade de incluir detalhes de implementação de código — o código em si serve como a documentação mais detalhada.

📖 Resumo


📝 Exercícios

  1. Tarefa Básica (Dificuldade: ⭐): Complete o documento de análise de requisitos do OrderFlow, listando todas as user stories e endpoints de API.

  2. Problema Avançado (Dificuldade: ⭐⭐): Complete o design ER do banco de dados e os statements DDL de criação de tabela, incluindo todos os índices. Desenvolva um formato de resposta padronizado e sistema de códigos de erro.

  3. Desafio (Dificuldade: ⭐⭐⭐): Use SpringDoc OpenAPI para escrever uma especificação de API e gerar uma página interativa de documentação de API. Considere como manter a documentação da API em sincronia com a implementação do código.

Web-Tutorial.com

Equipe Técnica Web-Tutorial

Uma plataforma de tutoriais mantida por diversos desenvolvedores. Cada tutorial é escrito e revisado por profissionais da área correspondente. Trabalhamos para manter nosso conteúdo preciso e confiável — se encontrar algum problema, avise-nos.

100%