Antes de escrever uma linha de código, engenheiros de software pensam em processo e arquitetura. Nesta aula você entende como um sistema nasce, evolui e é documentado — e aprende a enxergar qualquer sistema em 4 níveis de zoom com o modelo C4.
ciclo de vidawaterfall vs iterativomodelo C4contexto · container · component · codedocumentar antes de codificar
Imagine que você foi contratado para construir um sistema de delivery. Você abre o editor e começa a digitar? Não. Um engenheiro experiente primeiro responde: quem usa? quais partes existem? como elas se comunicam? O processo de software começa muito antes do código.
💡
analogia do dia a dia
Construir um sistema sem planejar é como construir uma casa sem planta. Você pode até levantar as paredes, mas vai derrubar tudo quando precisar passar a fiação elétrica.
Waterfall vs Iterativo
Existem duas grandes filosofias sobre como conduzir um projeto de software. A primeira, chamada de Waterfall (cascata), trata o projeto como uma sequência rígida de fases. A segunda, iterativa, divide o trabalho em ciclos curtos onde você entrega, aprende e ajusta.
modelo waterfall — fases sequenciais
1
Requisitos
2
Design
3
Implementação
4
Testes
5
Deploy
↑ o usuário só vê o produto na fase 5. Se algo mudou na fase 1, tudo precisa ser refeito.
✕ Waterfall
Fases sequenciais sem volta
Usuário vê o produto meses depois
Mudança de requisito = recomeçar
Risco concentrado no final
Funciona bem em projetos estáveis
✓ Iterativo (Ágil)
Ciclos curtos de 1–2 semanas
Entrega contínua de valor
Mudança é bem-vinda a qualquer momento
Risco distribuído ao longo do projeto
Padrão da indústria de software web
⚡
por que o waterfall falha em projetos web
A web muda rápido. O que o usuário queria em janeiro pode não ser o que ele precisa em março. O modelo ágil nasceu exatamente para lidar com essa realidade: abraçar a mudança, não lutar contra ela.
Modelo C4 — 4 níveis de zoom
O modelo C4, criado por Simon Brown, é uma forma de documentar e comunicar arquitetura de software usando 4 níveis de abstração. A ideia é simples: assim como um mapa pode mostrar o mundo inteiro ou a rua onde você mora, um diagrama de sistema pode mostrar desde a visão geral até o detalhe do código.
analogia — Google Maps
Google Maps
Zoom 1: País inteiro
Zoom 2: Cidade
Zoom 3: Bairro e ruas
Zoom 4: Número da porta
⟺
Modelo C4
C1: Sistema no mundo
C2: Containers do sistema
C3: Componentes internos
C4: Código (classes/funções)
clique em cada nível para ver detalhes
C1
Context — o sistema no mundo
Quem usa o sistema? Com quais outros sistemas ele se comunica?
visão geral 👤 usuários e sistemas
O diagrama de Contexto responde: qual é o propósito do sistema? Ele mostra o sistema como uma caixa preta no centro, cercado pelos usuários e sistemas externos com quem ele se comunica. É o ponto de partida de qualquer conversa técnica. Exemplo: App de Delivery → [Usuário, Restaurante, Gateway de Pagamento, Sistema de Mapas].
C2
Container — as peças do sistema
Quais aplicações e serviços compõem o sistema? Como se comunicam?
arquitetura 🖥️ apps e serviços
Container aqui não significa Docker — significa qualquer processo executável ou armazenamento de dados: uma aplicação web, uma API, um banco de dados, um app mobile. O diagrama C2 mostra como esses containers se comunicam entre si. Exemplo: [React App] → HTTP/JSON → [API Node.js] → SQL → [PostgreSQL].
C3
Component — o interior de um container
Quais módulos/serviços compõem um container específico?
módulos 📦 componentes lógicos
O diagrama de Componentes faz zoom dentro de um container específico e mostra suas partes internas. Exemplo: dentro da API Node.js temos [AuthController] [OrderService] [PaymentGateway] [UserRepository]. Cada componente tem uma responsabilidade clara — exatamente o que SOLID vai reforçar.
C4
Code — classes e funções
Como um componente é implementado? Diagrama de classes opcional.
implementação 💻 código fonte
O nível de código é raramente necessário — a maioria dos projetos ágeis para no C3, pois o código em si já documenta esse nível. Quando usado, é um diagrama UML de classes mostrando métodos, atributos e relações de herança/composição. Ferramentas como Mermaid.js ou PlantUML geram esses diagramas a partir do código.
C4 na prática com Mermaid
O C4 pode ser desenhado em ferramentas como draw.io, Structurizr ou diretamente em código com Mermaid.js. Nos projetos modernos, o diagrama vive junto com o código no repositório Git — ele evolui junto com o sistema.
mermaid — C2 Container Diagram
%% Diagrama C2 — App de Deliverygraph TD
User["👤 Usuário\n(browser/mobile)"]
Admin["👤 Administrador\n(browser)"]
subgraphSistema de DeliveryWeb["🌐 Web App\n(React · porta 3000)"]
API["⚡ API REST\n(Node.js/Express · porta 4000)"]
DB["🗄️ Banco de dados\n(PostgreSQL · porta 5432)"]
Cache["⚡ Cache\n(Redis · porta 6379)"]
endPay["💳 Gateway Pagamento\n(Stripe API)"]
Maps["🗺️ Mapas\n(Google Maps API)"]
User -->|"HTTPS"| WebAdmin -->|"HTTPS"| WebWeb -->|"REST/JSON"| APIAPI -->|"SQL"| DBAPI -->|"Redis Protocol"| CacheAPI -->|"HTTPS"| PayAPI -->|"HTTPS"| Maps
🔗
C4 + SDD + IA — a conexão que veremos na Aula 9
Quando você entrega esse diagrama para uma IA como Claude Code ou Copilot, ela consegue gerar scaffolding de código consistente com a arquitetura definida. Especificar antes de codificar é o coração do SDD — Specification-Driven Development.
⚡
quiz · aula 01
Teste seus conhecimentos
0/3 respondidas
QUESTÃO 01
O diagrama C2 do modelo C4 mostra qual nível de detalhe?
QUESTÃO 02
Por que o modelo Waterfall falha frequentemente em projetos web?
QUESTÃO 03
No modelo C4, o que "Container" significa — diferente do Docker?