O pagamento
vira história.

O pedido foi pago. Quem mais quer saber? [01]

No Cap 02, Pedidos e Pagamentos passaram a conversar por mensagens no RabbitMQ. Pedidos deixa uma solicitação na fila, Pagamentos decide quando puder, e o resultado volta por outra fila. No fim, o pedido fica PAGO.

Hoje usamos o Apache Kafka. Ele também transporta mensagens, mas funciona como um caderno de registros: o que foi escrito fica escrito, e quem chega depois ainda pode ler desde o começo. Essa diferença vai ficar visível nos simuladores antes de qualquer código.

Os pagamentos continuam simulados. APROVAR e RECUSAR são cenários de aula; não há dinheiro real envolvido.

O plano da tarde [02]

Quatro partes. Primeiro a ideia (por que um caderno e não uma fila), com três simuladores. Depois montamos com o agente a Loja Café sem Kafka: front, API e um Pagamentos chamado por HTTP, até o problema aparecer na tela. Então o Kafka entra no meio, e um serviço que chega depois lê a história inteira. No fim, comparamos RabbitMQ com Kafka.

📓 Abrir caderno livre · Baixar collection do Insomnia (Loja Café) · Guia de execução e recuperação

O plano de hoje: sair do zero no Kafka [03]

O objetivo é que você saia sabendo o que é o Kafka, por que ele existe ao lado do RabbitMQ e onde ele faz diferença num sistema de verdade. Por isso a tarde tem duas metades: primeiro a ideia, sem ferramenta; depois um sistema que você monta com o agente, sem Kafka e com Kafka.

1. Ideia (vídeos + simuladores): fila × log, offset, grupos, partições e chave.
2. Sem Kafka: a Loja Café com React, Spring e um Pagamentos em Python chamado por HTTP. Funciona, até o Pagamentos cair.
3. Com Kafka: o mesmo sistema, a mesma tela, as peças conversando por eventos. Um leitor que chega depois lê a história inteira.

A fila entrega e esquece [04]

Um caderno que só cresce: log e offset [05]

Cada grupo, seu marcador [06]

Partições e chave: onde fica a ordem [07]

Seis peças, uma função cada [08]

Você já viu todas. Este quadro é para consultar, não para decorar. A última coluna liga cada peça ao que você já conhece do RabbitMQ.

A Loja Café, peça por peça [09]

Na Parte 1 você viu o caderno funcionando nos simuladores. Agora ele vai trabalhar num sistema. É uma cafeteria: o cliente escolhe no cardápio, a API grava o pedido e alguém precisa cobrar. Nada aqui é produção. O objetivo é ver, num sistema que você mesmo montou, onde o Kafka faz diferença.

Use os botões para ver o sistema crescer. Em cada ato este desenho volta, com a parte nova acesa. O botão ▶ Ver um pedido passar anima o caminho de um pedido naquele ato.

Prepare a bancada

1. Baixe o ponto de partida: loja-cafe-inicio.zip. Descompacte numa pasta sua, fora de qualquer outro projeto. Ele traz só o combinado, ainda sem código:
   loja-cafe/conteúdo do ZIP

   AGENTS.md        regras para o agente (portas, pastas, "não invente contrato")
   CLAUDE.md        uma linha: @AGENTS.md
   COMO-RODAR.md    o comando de cada peça
   specs/api.md         contrato REST da API de pedidos
   specs/pagamentos.md  regra do pagamento simulado
   specs/eventos.md     contrato dos eventos (só no Ato 3)
   infra/compose.yml    Kafka + painel, pronto

2. Confira as ferramentas num terminal. Cada comando deve responder uma versão:
   seu terminalCopiar

   java -version
   node -v
   python3 --version
   docker version

   Esperado: Java 21, Node 20 ou mais novo, Python 3.10 ou mais novo, e o Docker mostrando Server. No Windows, troque python3 por py.
3. Abra o agente dentro de loja-cafe/ (Claude Code, Codex ou Antigravity). Os prompts de hoje funcionam nos três, porque as regras estão no AGENTS.md.

A API de pedidos, em Spring [10]

[CONTEXTO] Estou na pasta loja-cafe. Leia AGENTS.md e specs/api.md. Hoje criamos só a pedidos-api; front e pagamentos vêm depois.
[TAREFA] Gere o projeto pelo Spring Initializr (start.spring.io, versão padrão do Spring Boot, Java 21, Maven) na pasta pedidos-api, pacote br.com.lojacafe.pedidos, com Spring Web, Spring Data JPA, H2 e Validation. Implemente exatamente o contrato de specs/api.md: entidade Pedido, repositório, POST /pedidos (valor = quantidade × precoUnitario, nasce AGUARDANDO_PAGAMENTO) e GET /pedidos (mais novo primeiro). H2 em arquivo (jdbc:h2:file:./dados/pedidos) para não perder os pedidos ao reiniciar. CORS liberado para http://localhost:5173.
[LIMITES] Sem camadas extras, sem DTO de saída (devolva a entidade), sem Lombok. Não crie front nem pagamentos.
[ACEITE] Rode pelo Maven Wrapper. Mostre um POST com resposta 201 e valor calculado, um POST inválido com 400 e o GET listando.
[PAUSA] Mostre os arquivos que vai criar e aguarde meu OK.
[COMMIT] Depois do meu OK sobre o resultado: git init (se ainda não houver) e commit "Ato 1: pedidos-api".

Prove você mesmo. Com a API rodando, num terminal novo:

curl -s -X POST localhost:8080/pedidos -H "Content-Type: application/json" -d '{"cliente":"Ana","item":"Café coado","quantidade":2,"precoUnitario":8.50}'

{"id":1,"cliente":"Ana","item":"Café coado","quantidade":2,"valor":17.0,
 "status":"AGUARDANDO_PAGAMENTO","motivo":null,"processadoPor":null,"criadoEm":"2026-10-17T..."}

@PostMapping
@ResponseStatus(HttpStatus.CREATED)
public Pedido criar(@Valid @RequestBody NovoPedido novo) {
    Pedido pedido = new Pedido(novo.cliente(), novo.item(), novo.quantidade(), novo.precoUnitario());
    return repository.save(pedido);
}

@GetMapping
public List<Pedido> listar() {
    return repository.findAllByOrderByIdDesc();
}

A vitrine, em React [11]

[CONTEXTO] A pedidos-api já roda na 8080 (specs/api.md). Agora a vitrine.
[TAREFA] Crie front/ com Vite + React em JavaScript (npm create vite@latest front -- --template react). Uma página só: campo nome do cliente; cardápio com 4 itens fixos (Café coado 8,50 · Cappuccino 12,00 · Pão de queijo 6,00 · Bolo de cenoura 9,50); quantidade de 1 a 50; total calculado; botão Fazer pedido que fica "Enviando…" enquanto espera. Depois de cada envio, mostre "A API respondeu em N ms" (meça com performance.now()). Se der erro, mostre uma faixa vermelha com o status. Abaixo, a lista de pedidos com id, cliente, item, valor, status colorido (amarelo aguardando, verde pago, vermelho recusado), motivo e processadoPor, atualizada a cada 2 segundos pelo GET /pedidos.
[LIMITES] Sem TypeScript, sem biblioteca de UI, sem roteador, sem gerenciador de estado. Chamadas à API em src/api.js, com a URL http://localhost:8080. Não mexa na pedidos-api.
[ACEITE] npm run dev abre em http://localhost:5173; um pedido feito na tela aparece na lista como "Aguardando pagamento" e o tempo de resposta aparece.
[PAUSA] Aguarde meu OK antes de instalar dependências.
[COMMIT] Depois do meu OK: commit "Ato 1: front".

1. Abra localhost:5173, digite seu nome e faça um pedido.
2. Esperado: o pedido aparece no topo da lista, em amarelo, Aguardando pagamento. Embaixo do botão: A API respondeu em ~30 ms. Anote esse número. Ele vai mudar no Ato 2 e voltar no Ato 3.

// Pergunta à API a cada 2 segundos. Assim o status muda na tela sozinho.
useEffect(() => {
  const atualizar = () => listarPedidos().then(setPedidos).catch(() => {})
  atualizar()
  const id = setInterval(atualizar, 2000)
  return () => clearInterval(id)
}, [])

Pagamento por telefone: Flask via HTTP [12]

[CONTEXTO] Leia specs/pagamentos.md. Vamos criar o Pagamentos simulado, em Python, chamado pela API por HTTP.
[TAREFA] Crie pagamentos-py/ com .venv, requirements.txt (flask) e app.py: POST /pagamentos recebe {pedidoId, valor}, espera 3 segundos e responde APROVADO até R$ 100,00 ou RECUSADO com motivo "limite do cartão de teste"; GET /saude. Nome da instância em INSTANCIA (padrão caixa-1), porta em PORTA (padrão 5001). Imprima uma linha por decisão. Depois, na pedidos-api: logo após gravar o pedido, chame POST http://localhost:5001/pagamentos com RestClient, espere a resposta e atualize status, motivo e processadoPor antes de responder ao front.
[LIMITES] Não trate a falha do Pagamentos (sem try/catch, retry ou timeout especial): queremos ver o que acontece. Não mexa no front.
[ACEITE] Com os dois rodando: um pedido de R$ 17,00 volta PAGO na própria resposta, em cerca de 3 s; um de 20 cafés volta RECUSADO.
[PAUSA] Mostre o plano e aguarde meu OK.
[COMMIT] Depois do meu OK: commit "Ato 2: pagamento por HTTP".

Para rodar o Flask (o agente pode fazer isso por você), num terminal só dele:

cd pagamentos-py
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python app.py

No Windows, troque as linhas 2 e 3 por py -m venv .venv e .venv\Scripts\activate. O .venv é uma caixa só deste serviço para as bibliotecas Python; assim o Flask daqui não briga com nada instalado no seu computador.

1. Reinicie a API (ela mudou) e faça um pedido no front. O botão fica Enviando… por uns 3 segundos. Depois: A API respondeu em ~3 050 ms, e o pedido já chega Pago, com a etiqueta caixa-1.
2. Peça 20 cafés coados (R$ 170,00). Volta Recusado, com o motivo.

pedido = repository.save(pedido);

// Ato 2: o cliente fica esperando enquanto o Pagamentos decide (~3 s).
// Se o Pagamentos estiver fora, a exceção sobe e o cliente recebe 500,
// mas o pedido já foi gravado e fica AGUARDANDO para sempre.
PagamentosClient.Resposta resposta = pagamentos.pagar(pedido);
pedido.concluir("APROVADO".equals(resposta.status()), resposta.motivo(), resposta.instancia());
return repository.save(pedido);

Desligue o Pagamentos: o problema do telefone [13]

Funciona. Agora vamos ver o que acontece num dia ruim.

1. Pare o Flask (Ctrl+C no terminal dele) e faça um pedido no front.
2. Esperado: faixa vermelha, POST /pedidos respondeu 500. O cliente acha que não comprou.
3. Olhe a lista: o pedido está lá, Aguardando pagamento. E vai ficar assim para sempre, porque ninguém vai tentar cobrar de novo. O cliente viu erro, a loja tem um pedido órfão.

Suba o Kafka e combine os eventos [14]

O compose já está no ZIP inicial. Ele sobe só o Kafka e o painel; a API, o front e o Flask continuam rodando no seu computador.

docker compose up -d --wait

Esperado: Container loja-cafe-kafka-1 Healthy e Container loja-cafe-kafka-ui-1 Healthy. Abra o painel em localhost:8090: o cluster aula aparece online, ainda sem tópicos seus.

O contrato dos eventos (specs/eventos.md)

Na Parte 1, o exemplo era um tópico só, pedidos-pagos. Na Loja Café são dois, um em cada direção: pedidos-criados (a API conta que um pedido nasceu) e pagamentos-resultados (o Pagamentos conta o que decidiu).

chave: "12"
valor: { "versao": 1, "pedidoId": 12, "cliente": "Ana", "item": "Café coado",
         "quantidade": 2, "valor": 17.00, "criadoEm": "2026-10-17T16:05:00Z" }

chave: "12"
valor: { "versao": 1, "pedidoId": 12, "status": "APROVADO", "motivo": null,
         "instancia": "caixa-1", "processadoEm": "2026-10-17T16:05:03Z" }

Troque o telefone pelo caderno [15]

Dois prompts, um para cada lado. A API passa a anotar o pedido no tópico e responder na hora. O Pagamentos deixa de ser chamado: ele lê o tópico, decide e anota o resultado em outro tópico, que a API lê para atualizar o status.

[CONTEXTO] Leia specs/eventos.md. O Kafka está rodando (infra/compose.yml, localhost:9092). Vamos trocar a chamada HTTP ao Pagamentos por eventos.
[TAREFA] Na pedidos-api: adicione o starter de Kafka do Spring Boot. Crie os tópicos pedidos-criados e pagamentos-resultados (3 partições, 1 réplica) com beans NewTopic. Depois de gravar o pedido, publique PedidoCriado em pedidos-criados com chave = pedidoId e valor = JSON em texto, e espere a confirmação do broker (get com 5 s). Remova a chamada HTTP ao Pagamentos. Crie um @KafkaListener em pagamentos-resultados (grupo pedidos-api, auto-offset-reset earliest) que atualiza status, motivo e processadoPor; se o pedido já não estiver AGUARDANDO, ignore (resultado repetido). Configure max.block.ms=5000 no produtor.
[LIMITES] Chave e valor como String. Converta o JSON com o JsonMapper do próprio Spring Boot; não use o JsonSerializer do Spring Kafka (ele grava o tipo Java num header e o Python não precisa disso). Não mexa no front.
[ACEITE] POST /pedidos responde em menos de 1 s com AGUARDANDO_PAGAMENTO, e o tópico pedidos-criados aparece em http://localhost:8090 com a mensagem do pedido.
[PAUSA] Mostre o plano e aguarde meu OK.
[COMMIT] Depois do meu OK: commit "Ato 3: pedidos-api no Kafka".

[CONTEXTO] Leia specs/eventos.md. A pedidos-api já publica em pedidos-criados. Agora o Pagamentos deixa de ser chamado: ele lê.
[TAREFA] Em pagamentos-py, adicione confluent-kafka. Numa thread separada, um consumidor do grupo pagamentos (auto.offset.reset earliest, broker.address.family v4) lê pedidos-criados, aplica a mesma regra (3 s, limite R$ 100) e publica o resultado em pagamentos-resultados com a mesma chave, no formato do contrato, incluindo instancia. Produtor com partitioner murmur2_random. Imprima partição, offset, pedido e decisão. Remova o POST /pagamentos; mantenha GET /saude e crie GET /pagamentos com o que esta instância processou. Rode o Flask com use_reloader=False e, no Ctrl+C, feche o consumidor.
[LIMITES] Sem Celery, sem asyncio, sem framework extra. Não mexa na pedidos-api nem no front.
[ACEITE] Com tudo rodando, um pedido feito no front aparece Aguardando e vira Pago em cerca de 3 s, sozinho. O log mostra partição e offset.
[PAUSA] Mostre o plano e aguarde meu OK.
[COMMIT] Depois do meu OK: commit "Ato 3: pagamentos lê do Kafka".

1. Reinicie a API e o Flask (instale antes a dependência nova: pip install -r requirements.txt, com o .venv ativo).
2. Não mexa no front. Faça um pedido. Esperado: A API respondeu em ~20 ms, o pedido aparece Aguardando e, uns 3 segundos depois, vira Pago sozinho.
3. No terminal do Flask:
   terminal do Pagamentosexemplo real

   [caixa-1] ouvindo pedidos-criados no grupo 'pagamentos'
   [caixa-1] partição 0 · offset 0 · pedido 5 -> APROVADO

4. No painel: Topics → pedidos-criados → Messages. O pedido está lá, com a chave igual ao id. Em pagamentos-resultados, a decisão.

var evento = new PedidoCriado(1, p.getId(), p.getCliente(), p.getItem(),
        p.getQuantidade(), p.getValor(), p.getCriadoEm());
// Chave = pedidoId: todos os eventos do mesmo pedido caem na mesma partição.
// .get() espera o "ok" do broker; se o Kafka estiver fora, a falha aparece aqui.
kafka.send("pedidos-criados", String.valueOf(p.getId()), json.writeValueAsString(evento))
        .get(5, TimeUnit.SECONDS);

@KafkaListener(topics = "pagamentos-resultados")
public void receber(String mensagem) {
    var resultado = json.readValue(mensagem, ResultadoPagamento.class);
    repository.findById(resultado.pedidoId()).ifPresent(pedido -> {
        // concluir() ignora repetição: o mesmo resultado duas vezes não muda nada.
        if (pedido.concluir("APROVADO".equals(resultado.status()), resultado.motivo(), resultado.instancia())) {
            repository.save(pedido);
        }
    });
}

while not parar.is_set():
    msg = consumidor.poll(1.0)          # espera até 1 s por uma mensagem
    if msg is None:
        continue
    pedido = json.loads(msg.value())
    status, motivo = decidir(float(pedido["valor"]))
    produtor.produce("pagamentos-resultados", key=str(pedido["pedidoId"]), value=json.dumps(resultado))
    produtor.flush()

Desligue o Pagamentos de novo [16]

1. Pare o Flask (Ctrl+C) e faça três pedidos seguidos no front.
2. Esperado: nenhuma faixa vermelha. A API responde em milissegundos e os três ficam Aguardando.
3. No painel: Consumers → pagamentos. A coluna Consumer Lag mostra 3: três registros escritos que o grupo ainda não leu.
4. Ligue o Flask. Ele lê os três, um a cada 3 segundos, imprimindo partição e offset. Na tela, os três viram Pago. O lag volta a 0.

Quem chega depois lê o passado [17]

[CONTEXTO] Leia specs/eventos.md. Já existem pedidos no Kafka. Quero um serviço novo que chega agora, sem que ninguém o avise.
[TAREFA] Crie analytics-py/ com .venv, requirements.txt (confluent-kafka) e analytics.py: um consumidor com group.id vindo da variável GRUPO (padrão analytics), auto.offset.reset earliest e broker.address.family v4, lendo pedidos-criados e pagamentos-resultados. Guarde num dicionário em memória, indexado por pedidoId, item, quantidade, valor e status (vale o primeiro status recebido). Para cada mensagem, imprima tópico, partição, offset e pedido; depois de cada lote, um painel: pedidos vistos, pagos, faturamento (soma dos aprovados) e item mais vendido. Ctrl+C fecha o consumidor.
[LIMITES] Sem banco, sem Flask, sem arquivo: o painel vive só na memória, de propósito. Não mexa em nenhuma outra pasta.
[ACEITE] Na primeira execução, o painel mostra os pedidos feitos antes de o Analytics existir.
[PAUSA] Mostre o plano e aguarde meu OK.
[COMMIT] Depois do meu OK: commit "Ato 4: analytics".

1. Primeira execução. Em analytics-py, com o .venv ativo: python analytics.py. Ele lê tudo desde o offset 0:
   terminal do Analyticsexemplo · os seus números serão outros

   Analytics lendo no grupo 'analytics'. Ctrl+C para sair.
     pedidos-criados        partição 0 · offset   0 · pedido 1
     pagamentos-resultados  partição 0 · offset   0 · pedido 1
     pedidos-criados        partição 2 · offset   0 · pedido 2
     ...
   📊 pedidos vistos: 9 · pagos: 7 · faturamento: R$ 94.00 · mais vendido: Café coado (6)

   Confira com a tela do front: os números batem com os pedidos que você fez antes de o Analytics existir.
2. Faça um pedido novo no front. O Analytics imprime a linha e o painel sobe, ao vivo.
3. Feche (Ctrl+C) e rode de novo. Antes de rodar, responda:

   O que o painel vai mostrar na segunda execução?

   Tudo de novo, desde o offset 0.Nada: o marcador ficou no Kafka, mas o painel estava na memória.

   Escolha uma previsão. Depois confira a explicação.

   Tentar novamente
4. Rebobine. Com o Analytics parado (o reset exige grupo sem ninguém lendo), em infra/:
   seu terminal, em loja-cafe/infraCopiar

   docker compose exec kafka /opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server kafka:19092 --group analytics --all-topics --reset-offsets --to-earliest --execute

   Rode o Analytics de novo: o painel inteiro volta, igual. Isso é replay. O painel é uma visão derivada do log: pode ser jogado fora e reconstruído.
5. Um time novo. Rode com outro grupo: GRUPO=auditoria python analytics.py (PowerShell: $env:GRUPO="auditoria"; python analytics.py). Lê tudo, com marcador próprio, sem mexer no do analytics.

Dois caixas no mesmo grupo [18]

É o simulador do ponto 07, de verdade. Dois consumidores no mesmo grupo dividem as partições: cada pedido é cobrado por um caixa só, e o trabalho anda em paralelo. Não muda uma linha de código, só sobe outra instância.

INSTANCIA=caixa-2 PORTA=5002 python app.py

No PowerShell: $env:INSTANCIA="caixa-2"; $env:PORTA="5002"; python app.py.

1. Faça seis pedidos rápidos. Na lista, as etiquetas alternam entre caixa-1 e caixa-2, conforme a partição de cada pedido.
2. No painel: Consumers → pagamentos. Duas instâncias, cada uma com as suas partições (com 3 partições, uma fica com duas).
3. Ctrl+C no caixa-2. Em poucos segundos o grupo se rebalanceia e o caixa-1 volta a cuidar das três partições.

Kafka desligado: o pedido existe, o evento não [19]

1. Em infra/, pare só o Kafka: docker compose stop kafka.
2. Faça um pedido. O botão fica Enviando… uns 5 segundos e aparece a faixa vermelha (500). Na lista, o pedido está lá, Aguardando.
3. Suba o Kafka: docker compose up -d --wait. Faça outro pedido: esse funciona. O órfão continua Aguardando.
4. Peça ao agente o diagnóstico e uma proposta de correção (Prompt 7). Não deixe ele implementar antes de você entender.

[CONTEXTO] Desliguei o Kafka, fiz um pedido, recebi 500 e liguei o Kafka de novo. O pedido ficou AGUARDANDO_PAGAMENTO para sempre.
[TAREFA] Sem editar arquivos, explique com evidências o que aconteceu: o pedido no GET /pedidos, as linhas de erro do log da API e as mensagens do tópico pedidos-criados (o pedido órfão não está lá). Depois proponha o padrão outbox para este projeto: tabela, momento da gravação, quem publica, de quanto em quanto tempo, e o que acontece se publicar duas vezes.
[LIMITES] Não use down -v, não apague dados, não reinicie nada sem me perguntar.
[ACEITE] Diagnóstico em cinco frases, com a evidência de cada uma. Proposta de outbox em até dez linhas, citando por que a pedidos-api já aguenta evento repetido.
[PAUSA] Aguarde meu OK antes de qualquer implementação.

RabbitMQ ou Kafka? Depende da pergunta [20]

Nenhum dos dois é “melhor”. São modelos diferentes. Este é o quadro que você leva para o resto do curso. Na AWS, mais adiante, vamos acrescentar uma terceira coluna.

O agente fez quatro propostas. Para cada uma, decida se você defende ou refuta, e diga a frase que usaria na revisão.

Explique o sistema sem decorar comandos [21]

1. No Ato 2, por que o cliente esperou 3 segundos e por que o pedido ficou órfão quando o Flask caiu? O que mudou no Ato 3?
2. Em que momento da tarde o Kafka fez algo que a fila do Cap 02 não faria?
3. Onde fica o marcador do grupo analytics, e por que rodar o Analytics de novo mostrou um painel vazio?
4. Por que a chave é o pedidoId? Com 3 partições, quantos caixas trabalham, e o quarto?
5. O que acontece entre gravar no H2 e publicar no Kafka, e qual é o nome da solução definitiva?

Traga provas e o seu quadro [22]

1. Termine os atos que ficaram pela metade, inclusive o Ato 5 (ponto 18). Travou? Continue pelo ZIP do ato anterior, listado no ponto 09.
2. Provoque a escrita dupla (ponto 19) e rode o Prompt 7. Guarde o diagnóstico do agente.
3. Repetição de propósito: no painel do Kafka, Topics → pagamentos-resultados → Produce Message, publique de novo o resultado de um pedido já pago, com a mesma chave, trocando o status para RECUSADO. Preveja antes: o pedido muda na tela? E o painel do Analytics?
4. Um terceiro leitor, sem tocar na API: peça ao agente um notificacoes-py, grupo notificacoes, que imprime “Olá Ana, seu pedido #12 foi pago!” para cada resultado aprovado. Conte quantas linhas da API você mudou.
5. Escreva o seu quadro RabbitMQ × Kafka com suas palavras, em specs/quando-usar-qual.md: três critérios que você mais usaria e um exemplo da Loja Café para cada.
6. Entregue o link do repositório (um commit por ato) e três frases: “O marcador do grupo fica… Rodar de novo zerou porque… O replay reconstruiu porque…”.
7. Leia antes do próximo sábado o capítulo de OO de verdade e SOLID, a base do Cap 04.