Aula de Hoje

Arquitetura em Camadas

Como organizar sistemas em níveis hierárquicos com responsabilidades isoladas

// Arquitetura em Camadas
Layer N   (Aplicação)
   ↓ request
Layer N-1 (Negócio)
   ↓ request
Layer 2   (Dados)
   ↓ request
Layer 1   (Infraestrutura)
   ↑ response
💡

Separar responsabilidades em camadas independentes que só comunicam com vizinhas

🗂️
🧑‍💻
Vamos aprender! 🚀
O Problema

O Problema

Sem organização em camadas, sistemas tornam-se monolitos acoplados onde qualquer mudança afeta tudo, dificultando manutenção, testes e evolução do software.

🔗
Acoplamento total
Qualquer alteração em uma parte quebra o sistema inteiro
⚠️
Manutenção impossível
Sem fronteiras claras, ninguém sabe onde mexer
🔄
Zero reusabilidade
Código misturado não pode ser aproveitado em outros contextos

🌱 Precisamos de fronteiras claras — é aí que a Arquitetura em Camadas resolve tudo!

sem camadas
// Sem camadas: tudo misturado!
function processarPedido(dados) {
  const html = renderizarUI(dados);
  const total = dados.qtd
    * buscarPrecoNoBanco(dados.id);
  // SQL direto na lógica de negócio!
  const sql = 'INSERT INTO pedidos'
    + ' VALUES (' + total + ')';
  executarSQL(sql);
  enviarEmail(dados.email, html);
}
A Solução

Arquitetura em Camadas

Organizamos o sistema em níveis hierárquicos onde cada camada tem responsabilidade única e se comunica apenas com a camada imediatamente adjacente.

Separação de responsabilidades — cada camada faz uma coisa só
Substituição independente — troque uma camada sem afetar as outras
Testabilidade — cada nível pode ser testado com mocks da camada inferior
Reusabilidade — camadas inferiores servem múltiplos sistemas

🏆 Com camadas bem definidas o sistema cresce com ordem e qualquer parte pode evoluir independentemente!

🏆 SISTEMA ORGANIZADO
Layer NAplicação/UI
▾▾▾
Layer N-1Lógica Negócio
▾▾▾
Layer 2Acesso a Dados
▾▾▾
Layer 1Infraestrutura
👨‍🏫
Exemplo da Vida Real

Analogia

🍽️

Restaurante com Brigada de Cozinha

Um restaurante organiza trabalho em papéis especializados que comunicam apenas com o nível adjacente — igual às camadas de software

1
Garçom (UI): Recebe pedido do cliente, repassa para a cozinha
2
Chef (Negócio): Define como o prato será feito, delega ao cozinheiro
3
Cozinheiro (Dados): Busca ingredientes na dispensa e prepara
4
Dispensa (Infra): Armazena e fornece os ingredientes necessários

💡 Garçom não vai à dispensa, cozinheiro não fala com cliente — cada um comunica só com o nível adjacente!

🍽️
🗂️
Garçom não vai à dispensa, cozinheiro não fala com cliente — cada um comunica só com o nível adjacente!
Código

Código na Prática

Python
# 3 camadas bem separadas — Python

# CAMADA 1: Infraestrutura
class RepositorioPedidos:
    def salvar(self, pedido):
        db.execute('INSERT INTO pedidos...', pedido)

# CAMADA 2: Lógica de Negócio
class ServicoPedidos:
    def __init__(self, repo):
        self.repo = repo
    def criar_pedido(self, dados):
        pedido = Pedido(dados)
        pedido.calcular_total()  # regra aqui!
        return self.repo.salvar(pedido)

# CAMADA 3: Apresentação
class Controlador:
    def __init__(self, servico):
        self.servico = servico
    def post_pedido(self, request):
        return self.servico.criar_pedido(request.dados)

📋 O que acontece:

1.Repositório fala apenas com o banco — infraestrutura pura
2.Serviço fala apenas com o Repositório — regras de negócio isoladas
3.Controlador fala apenas com o Serviço — apresentação separada

🔑 Cada camada só conhece a imediatamente abaixo — nunca pula camadas!

// Como usar
repo = RepositorioPedidos()
servico = ServicoPedidos(repo)
ctrl = Controlador(servico)
Onde É Usado

Casos de Uso Reais

🌐

TCP/IP e OSI

  • 7 camadas de protocolo de rede
  • Cada camada encapsula a inferior
  • Base da internet moderna
🖥️

Web MVC / 3-Tier

  • View (apresentação)
  • Controller / lógica de negócio
  • Model / acesso a dados
📱

Sistemas Operacionais

  • Aplicativos de usuário no topo
  • Kernel no meio
  • Hardware na base
☁️

Sistemas Distribuídos

  • Middleware como camada de separação
  • Transparência de distribuição
  • IF Goiano — Grad.SD.02
Análise Crítica

Prós e Contras

Entender ambos os lados ajuda a escolher a ferramenta certa para o contexto certo!

✅ PRÓS

✅ Separação clara
Cada camada tem responsabilidade única e bem definida
✅ Manutenibilidade
Mudanças ficam localizadas — alterar uma camada não afeta as outras
✅ Testabilidade
Mock da camada inferior permite testar cada nível isoladamente
✅ Reusabilidade
Camadas de infra e dados podem ser compartilhadas entre sistemas

❌ CONTRAS

❌ Latência adicional
Cada camada adiciona overhead — requisições passam por todos os níveis
❌ Rigidez hierárquica
Comunicação entre camadas não adjacentes exige workarounds
❌ Complexidade inicial
Exige planejamento e disciplina — custo maior no início do projeto

💡 Use quando clareza e manutenção superam o custo de latência!

Resumo Final

O que aprendemos

Propósito

Organizar componentes em níveis hierárquicos com responsabilidades isoladas

Como Funciona

Cada camada serve à superior e consome a inferior via interfaces bem definidas

Benefício Principal

Manutenção, teste e evolução independente de cada nível do sistema

Quando Usar

Sempre que o sistema precisar de organização clara e crescimento controlado

🔑 Pontos-Chave

Camadas comunicam apenas com vizinhas imediatas

Variações: downcall, one-way call, upcall (callback)

Base do TCP/IP, OSI, MVC e arquiteturas 3-tier

Middleware é a camada de separação nos SDs

🎉

Arquitetura em Camadas é o fundamento de quase todo sistema moderno. Dominar esse conceito é dominar a base da engenharia de software distribuída!

IF GOIANO · Campus Rio Verde · Prof. Andrea B. Proto Sardi · Sistemas Distribuídos · Grad.SD.02