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
- Charlie propôs os seguintes requisitos de negócio: quatro módulos principais — Gerenciamento de Usuários, Gerenciamento de Produtos, Gerenciamento de Pedidos e Gerenciamento de Pagamentos
- Decisões de Seleção de Tecnologia: WebMVC vs. WebFlux, Session vs. JWT, Cache Local vs. Redis
- Design de Diagrama ER do Banco de Dados: Estruturas de Tabelas para User, Product, Order, OrderItem e Payment
- Design de Especificação RESTful API: Nomenclatura de URI / Versionamento / Paginação e Ordenação / HATEOAS
- Alice desenvolve o plano de desenvolvimento e atribui responsabilidades para cada módulo
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:
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
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:
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
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
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:
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
// 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:
// Execução bem-sucedida
(3) ▶ Exemplo: Parâmetros de Paginação e Ordenação
# 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:
// 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
# 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
📖 Resumo
- A análise de requisitos define os quatro módulos principais e a matriz de acesso por papéis
- Seleção de tecnologia usando uma matriz de decisão para comparação: WebMVC + JWT + cache de dois níveis + MySQL + JPA
- Design ER do banco de dados com cinco tabelas; índices cobrem consultas de alta frequência
- A especificação de API padroniza nomenclatura de URI, versionamento, paginação e ordenação, e formatos de resposta
- O plano de desenvolvimento é dividido em 4 sprints, com cada sprint durando 2 semanas
- Documentos de design de projeto servem como o "contrato" da equipe de desenvolvimento
📝 Exercícios
-
Tarefa Básica (Dificuldade: ⭐): Complete o documento de análise de requisitos do OrderFlow, listando todas as user stories e endpoints de API.
-
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.
-
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.



