Arquitetura de software e princípios SOLID, DRY, KISS e YAGNI

Do zero

Arquitetura de software é a planta da cidade, não a de cada casa: decide quais são os bairros (os grandes blocos do sistema), como as ruas os ligam (como os blocos conversam) e o que fica em cada um. Mudar uma casa é fácil; mudar o traçado da cidade é caro. Por isso a arquitetura vem antes.

Três desenhos de cidade que o edital cobra:

• Em camadas: um restaurante. O salão atende o cliente (apresentação), a cozinha prepara (regras de negócio) e a despensa guarda (dados). O garçom não entra na despensa: cada camada só fala com a vizinha.
• Microsserviços: em vez de uma loja gigante (o monolito), um shopping de lojas pequenas. Cada uma tem o seu estoque (o seu banco de dados), abre e fecha sem depender das outras e conversa com elas por um balcão combinado (uma API).
• Orientada a eventos: o alto-falante do shopping. Uma loja anuncia “chegou mercadoria” (um evento), e quem se interessa reage, sem que a loja precise saber quem está ouvindo.

Dentro de cada bloco, valem os princípios de projeto, regras de boa construção: cada peça faz uma coisa só (coesão alta), as peças dependem pouco umas das outras (acoplamento baixo), e os princípios SOLID, DRY, KISS e YAGNI dizem como chegar lá.

Frase para guardar: camadas separam por função, microsserviços separam por negócio, eventos avisam sem saber quem ouve; alta coesão, baixo acoplamento.

Em 1 minuto

• SOLID, um princípio por letra:
  • S, responsabilidade única: uma classe tem um só motivo para mudar.
  • O, aberto/fechado: aberta para extensão, fechada para modificação (acrescenta-se comportamento sem mexer no que funciona).
  • L, substituição de Liskov: um subtipo tem de poder substituir o tipo base sem quebrar quem o usa.
  • I, segregação de interfaces: várias interfaces pequenas e específicas, em vez de uma grande; ninguém depende de métodos que não usa.
  • D, inversão de dependência: depender de abstrações (interfaces), não de implementações concretas.
• DRY (não se repita): cada regra fica num lugar só. KISS (mantenha simples): a solução mais simples que resolve. YAGNI (você não vai precisar disso): não construir hoje o que talvez se peça amanhã.
• SOA (arquitetura orientada a serviços): serviços de negócio reutilizáveis, com contratos formais, muitas vezes integrados por um barramento (ESB) e SOAP. Microsserviços: serviços menores, implantados de forma independente, cada um com seus dados, comunicando-se por APIs leves (REST, gRPC) ou mensagens.
• Eventos: produtores publicam, consumidores assinam (publicar e assinar, ou pub/sub), por um intermediário de mensagens, como Kafka ou RabbitMQ. Ganha-se desacoplamento; aceita-se consistência eventual.
• Outros padrões arquiteturais: cliente-servidor, MVC (modelo, visão e controlador), hexagonal (portas e adaptadores) e pipes and filters (dutos e filtros).

Exemplo concreto: o sistema de protocolo cresce

Começo, um monolito em camadas. Uma aplicação só, com três camadas: as telas (apresentação), as regras do protocolo (negócio) e o acesso ao banco (dados). Simples de construir e implantar: KISS.

Depois, microsserviços com eventos. O sistema cresceu, e cada parte muda num ritmo. A equipe separa três serviços: Protocolo, Distribuição e Notificação. Quando um processo é protocolado, o serviço Protocolo publica o evento ProcessoProtocolado. A Distribuição sorteia o relator; a Notificação avisa o interessado por e-mail. Se a Notificação cair, o protocolo continua funcionando, e os avisos saem quando ela voltar.

Dentro da Notificação, o SOLID. O primeiro código dependia direto do e-mail:

class ServicoDeNotificacao {
    private EmailSmtp email = new EmailSmtp();   // preso a uma implementação concreta
    void avisar(String msg) { email.enviar(msg); }
}

Para acrescentar SMS, seria preciso mexer na classe. Com uma abstração, não:

interface Canal { void enviar(String msg); }

class EmailSmtp implements Canal { public void enviar(String msg) { /* envia e-mail */ } }
class Sms       implements Canal { public void enviar(String msg) { /* envia SMS */ } }

class ServicoDeNotificacao {
    private final Canal canal;                   // depende da abstração
    ServicoDeNotificacao(Canal canal) { this.canal = canal; }
    void avisar(String msg) { canal.enviar(msg); }
}

O serviço passou a depender da interface Canal (inversão de dependência), e um canal novo entra como classe nova, sem alterar o serviço (aberto/fechado). E ninguém construiu ainda o canal de WhatsApp “que talvez peçam”: YAGNI.

Comparação: estilos arquiteturais e princípios

Como a FCC cobra

• Coesão e acoplamento (o que se busca: alta coesão, baixo acoplamento).
• DRY, KISS e YAGNI num cenário.
• Monolito × microsserviços: vantagens e custos.
• MVC e camadas.

Pegadinhas

Explique com suas palavras

Explique a um gestor por que o sistema de notificação foi desenhado com uma interface Canal, e que princípios isso aplica, usando o exemplo de acrescentar o envio por SMS.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

No começo, o serviço de notificação estava preso ao e-mail: ele mesmo criava o envio de e-mail lá dentro. Para mandar SMS, seria preciso abrir e alterar esse serviço, correndo o risco de estragar o que já funcionava.

Com a interface Canal, o serviço passou a dizer só “eu preciso de algo que saiba enviar uma mensagem”, sem se importar se é e-mail ou SMS. Para acrescentar o SMS, basta criar uma peça nova que saiba enviar SMS e entregá-la ao serviço. Isso aplica dois princípios: o serviço depende de uma abstração, e não de um envio específico (inversão de dependência), e o sistema cresce acrescentando peças, sem modificar as antigas (aberto/fechado).

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso que peça uma arquitetura, não comece por microsserviços. Justifique: o tamanho da equipe, a necessidade de escalar partes diferentes, a frequência de mudança de cada parte. Um monolito modular em camadas, com módulos coesos e pouco acoplados, pode evoluir para serviços depois. Se houver integração entre sistemas que não devem esperar uns pelos outros (protocolo, distribuição, notificação), proponha eventos com um intermediário de mensagens.

Fontes da lição

• Edital nº 01/2026, Anexo II, Engenharia de Software (fontes/edital-01-2026.txt).
• Robert C. Martin, Arquitetura limpa (princípios SOLID, coesão e acoplamento).
• Martin Fowler e James Lewis, “Microservices” (2014).
• Andrew Hunt e David Thomas, O programador pragmático (DRY).
• Len Bass, Paul Clements e Rick Kazman, Software Architecture in Practice (estilos e padrões arquiteturais).