AULA 01 MÓDULO 0 processo de software ⏱ 60 min

Ciclo de vida e
modelo C4

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 vida waterfall vs iterativo modelo C4 contexto · container · component · code documentar 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 Delivery
graph TD
  User["👤 Usuário\n(browser/mobile)"]
  Admin["👤 Administrador\n(browser)"]

  subgraph Sistema de Delivery
    Web["🌐 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)"]
  end

  Pay["💳 Gateway Pagamento\n(Stripe API)"]
  Maps["🗺️ Mapas\n(Google Maps API)"]

  User  -->|"HTTPS"| Web
  Admin -->|"HTTPS"| Web
  Web   -->|"REST/JSON"| API
  API   -->|"SQL"| DB
  API   -->|"Redis Protocol"| Cache
  API   -->|"HTTPS"| Pay
  API   -->|"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?
0/3