DEV Community: Programador Filosofo

Pequenas decisões hoje podem virar grandes problemas amanhã

Programador Filosofo — Mon, 19 Jan 2026 13:59:09 +0000

Existe um tipo de problema em sistemas que não nasce grande. Ele nasce pequeno, quase invisível. Um if a mais para "resolver rápido", um log que ninguém revisa, uma dependência adicionada "só para essa telinha", um endpoint que responde rápido agora mas não foi pensado para suportar volume, um atalho de persistência porque "o domínio ainda vai mudar".

No dia em que você faz, parece inofensivo. Em três meses, vira um incômodo. Em um ano, vira uma parte do sistema que todo mundo evita mexer. E, quando o produto começa a crescer, aquele detalhe vira um gargalo, um risco operacional ou um custo de manutenção que suga tempo e energia do time.

Projetar sistemas é, em grande parte, aprender a enxergar esse filme antes de ele passar. Antecipar consequências, entender impacto e assumir responsabilidade pelo que acontece além da sua tela.

O que significa "responsabilidade além da sua tela"

Quando falamos em responsabilidade, não é "culpa", nem "heroísmo". É maturidade técnica. É entender que o seu código não existe para compilar, nem para passar no seu teste local. Ele existe para operar em um ambiente real, com:

tráfego irregular e picos imprevisíveis
dados incompletos, duplicados ou fora do padrão
integrações que falham
latência, timeouts e retries
deploys frequentes e rollback ocasional
times que mudam, pessoas que entram e saem
pressão do negócio, prazo e prioridades concorrentes

Nesse cenário, a sua decisão de hoje vira comportamento do sistema amanhã. E "amanhã" quase sempre inclui alguém tentando debugar um incidente às 2 da manhã, ou tentando entregar uma feature com medo de quebrar algo.

Pensar além da tela é projetar para esse mundo. Isso muda como você escreve código, como decide prioridades e como colabora com o time.

O mecanismo da bola de neve: por que o pequeno vira grande

Pequenas decisões viram grandes problemas por três motivos bem práticos.

1) Sistemas acumulam estado e dependências

Código é cumulativo. Um atalho vira base para outro atalho. Uma modelagem improvisada vira contrato com o banco e com APIs. Uma escolha de biblioteca vira padrão interno. Um endpoint mal definido vira referência para integrações externas.

Quanto mais o sistema cresce, mais caro fica "voltar e fazer direito", porque você já tem usuários, dados e dependências amarradas naquele comportamento.

2) A complexidade cresce de forma não-linear

Com 1 módulo, dá para "entender na cabeça". Com 10, começa a exigir disciplina. Com 30, o sistema vira um ecossistema. O que era um ajuste local passa a ter efeitos colaterais.

Exemplo clássico: "vou colocar esse campo como string e depois eu mudo". Quando chega o dia de mudar, você descobre que:

há dezenas de relatórios consumindo aquilo
existem validações em outros serviços esperando string
o banco tem índices e constraints baseadas no formato atual
existem dados históricos incompatíveis

O custo explode porque a decisão deixou de ser local.

3) Operação e manutenção são o verdadeiro preço

A maior parte do custo de software não está em escrever. Está em manter funcionando, evoluir com segurança e responder a incidentes.

Se você não projetou pensando em observabilidade, resiliência e mudanças, você não paga essa conta no dia que codou. Você paga aos poucos, toda semana, em forma de retrabalho, bugs regressivos, medo de deploy e lentidão nas entregas.

Antecipar consequências não é prever o futuro: é reduzir risco

Um erro comum é achar que "antecipar" significa prever exatamente o que vai acontecer. Não é. Sistemas reais mudam, produto muda, mercado muda. O que você consegue fazer é:

identificar decisões irreversíveis (ou muito caras de reverter)
desenhar para flexibilidade onde a mudança é provável
criar "guarda-corpos" para reduzir o impacto de falhas
tornar o sistema observável para que problemas sejam detectados cedo
evitar acoplamentos desnecessários

É mais próximo de engenharia do que de adivinhação.

Onde pequenas decisões mais cobram juros

Algumas áreas são particularmente sensíveis. É nelas que o "barato agora" fica caro depois.

1) Contratos de API e compatibilidade

Decidir o formato de um endpoint ou evento é criar um contrato. Contrato é política. E políticas mudam devagar.

Erros comuns:

endpoints muito "orientados à tela" (ex.: /getDashboardData) que acoplam backend a um front específico
respostas sem versionamento e sem tolerância a evolução
ausência de idempotência em operações críticas
semântica confusa (o que significa "status"? o que significa "cancelado"?)

Uma boa decisão aqui: projetar contratos com linguagem do domínio e com evolução em mente. Na prática:

evitar breaking changes desnecessárias
adicionar campos de forma backward-compatible
documentar comportamentos ambíguos
definir idempotency-key em operações de criação/pagamento/processamento

2) Modelagem de domínio e fronteiras

Modelar "mais ou menos" parece ok quando o sistema é pequeno. Quando cresce, a falta de clareza vira bug e regra duplicada.

Sinais de alerta:

"entidades anêmicas" com regras espalhadas em services utilitários
validações repetidas em camadas diferentes
regras de negócio no controller
nomes genéricos que escondem conceitos ("Data", "Info", "Helper")

Bons sistemas são bons em nomear e separar. Não é academicismo. É diminuir ambiguidade, reduzir duplicação e tornar a evolução mais segura.

3) Dados, integridade e migração

Decisões de dados costumam ser as mais caras de reverter: schema, constraints, índices, normalização, chaves, estratégia de migração.

O atalho clássico: "depois a gente arruma no banco". Depois vira:

migração complexa com downtime
necessidade de backfill de dados
inconsistência histórica
bugs sutis por dados inválidos

Se você quer valor sustentável, trate dados como ativo de longo prazo. Isso implica:

constraints para proteger integridade
migrações versionadas e revisadas
estratégia clara de evolução e compatibilidade
observação de performance desde cedo (índices, cardinalidade, queries críticas)

4) Observabilidade: logs, métricas e tracing

Sem observabilidade, você descobre problemas tarde. Ou descobre pelo cliente. E, quando descobre, não sabe onde está.

Uma pequena decisão hoje: "não vou colocar correlação de request agora". Amanhã:

ninguém consegue seguir o fluxo entre serviços
incidentes viram caça ao tesouro
o time perde confiança em deploys

Boas decisões:

log estruturado (com contexto: correlationId, userId, operation, latency)
métricas para SLIs/SLOs (p95/p99 de latência, taxa de erro, filas, timeouts)
tracing distribuído quando há múltiplos serviços
alarmes e dashboards simples, mas confiáveis

5) Resiliência: falhas acontecem, sempre

Integrações falham. Bancos oscilam. Cache expira. Rede dá jitter. O ponto não é evitar falhas. É evitar que falhas virem incidentes graves.

Pequena decisão hoje: "vou fazer retry em tudo". Amanhã:

você cria tempestade de retries e derruba o sistema
você agrava indisponibilidade do parceiro
você aumenta custo e latência sem perceber

Resiliência madura tem nuance:

retries com backoff e jitter
timeouts bem definidos
circuit breaker quando apropriado
filas/outbox para processamento assíncrono
idempotência para evitar duplicidade

6) Segurança e privacidade

Outra área em que o "só pra agora" vira dívida perigosa.

Pequenas decisões que viram bomba:

logar payloads com dados sensíveis
permissões amplas "porque depois restringe"
secrets em arquivo ou em variáveis sem rotação
falta de validação de entrada

Aqui, responsabilidade além da tela é literal. Você está lidando com dados de pessoas, dinheiro, reputação e compliance. Segurança não é um "check final". É um conjunto de escolhas no dia a dia.

O que muda no seu código quando você pensa assim

Pensar em valor sustentável muda a textura do código. Você começa a escrever com algumas perguntas na cabeça.

"Como isso falha?"

Não é pessimismo. É engenharia.

Se a API externa estiver fora, qual a experiência do usuário?
Se o banco estiver lento, o que acontece com o pool de conexões?
Se houver mensagens duplicadas, o sistema se comporta bem?
Se receber um payload inválido, eu falho com clareza?

"Como vou descobrir que falhou?"

Existe log suficiente para reproduzir o cenário?
Existe correlação para rastrear o fluxo?
Existe métrica para perceber degradação antes do caos?

"Isso cria acoplamento caro?"

Esse módulo está conhecendo detalhes demais de outro?
Estou misturando domínio com infraestrutura?
Estou amarrando a lógica ao framework, ou mantendo o core testável?

"Isso ajuda ou atrapalha o próximo desenvolvedor?"

Código é comunicação entre pessoas, mediado por máquina.

nomes expressam intenção?
existem invariantes explícitas?
os testes defendem o comportamento certo, ou só aumentam cobertura?

Quando você se preocupa com o próximo, você diminui o custo do time, não só o seu.

Prioridades: o jeito mais prático de projetar é saber o que não fazer

Projetar sistemas não é fazer tudo "perfeito". É tomar decisões conscientes sobre trade-offs. E, para isso, você precisa de critérios.

Um bom critério: priorizar decisões que são difíceis de reverter e baratas de fazer cedo.

Exemplos típicos:

definir contratos de API com cuidado
garantir idempotência em fluxos críticos
estabelecer padrões mínimos de observabilidade
criar limites claros entre domínio e integrações
automatizar build/test/deploy para reduzir risco de mudança

Em contrapartida, evite superengenharia em áreas instáveis. Se a regra de negócio ainda está mudando muito, talvez você não precise do modelo mais sofisticado do mundo. Mas você ainda precisa de testes, clareza e capacidade de evoluir.

Colaboração: arquitetura não mora em um documento, mora no time

"Assumir responsabilidade" não é um ato individual. Sistemas são construídos por times. E muitos problemas nascem não do código, mas da falta de alinhamento.

Pensar além da tela muda como você colabora:

você discute contratos e impactos antes de codar
você traz operação e suporte para a conversa quando necessário
você registra decisões importantes (não tudo, só o que é irreversível)
você cria padrões mínimos que reduzem variabilidade
você cria feedback loops (post-mortem sem caça às bruxas, melhorias incrementais)

Arquitetura boa não é "a mais bonita". É a que permite o time entregar com confiança e o produto crescer sem colapsar.

Um modelo mental útil: o custo total de uma decisão

Para decidir bem, vale olhar além do esforço de implementação.

Pergunte:

Custo de construir: tempo de dev, revisão, testes
Custo de operar: monitorar, incidentes, suporte
Custo de evoluir: mudar regra, adicionar feature, escalar
Custo de falhar: impacto para cliente, receita, reputação, compliance

Muitas decisões parecem baratas porque consideramos só o "custo de construir". Quando você incorpora o resto, muita coisa muda de categoria.

Como aplicar isso no dia a dia sem virar o "chato do time"

Existe um medo real: "se eu pensar em tudo, eu não entrego nada". A saída não é ignorar consequências. A saída é criar uma cadência prática.

1) Defina guarda-corpos mínimos

Exemplos:

padrões de logging
timeouts e retries com política clara
validação de entrada
testes mínimos para fluxos críticos
revisão de contrato de API

Guarda-corpos evitam que cada PR vire um debate filosófico.

2) Identifique o que é irreversível

Se é difícil de mudar depois, pare e pense mais agora:

schema do banco
eventos publicados
contrato público
estratégia de autenticação/autorização

3) Faça incrementos arquiteturais

Ao invés de refatorar tudo, faça melhorias pequenas e contínuas:

extrair um boundary
criar um adapter
introduzir idempotência
melhorar observabilidade de um fluxo
reduzir acoplamento em um módulo problemático

Isso cria valor sustentável sem travar roadmap.

4) Dê visibilidade para a dívida de forma honesta

Não é "a gente tem dívida técnica". Isso é abstrato. É: "esse fluxo hoje não é idempotente, então quando a fila duplicar mensagens, podemos processar duas vezes e gerar inconsistência. Custo para corrigir: X. Impacto: Y."

Quando você traduz em risco e custo, vira prioridade de negócio.

Fechando: valor sustentável é um hábito, não um evento

"Pequenas decisões hoje podem virar grandes problemas amanhã" não é frase de efeito. É um retrato fiel do que acontece em qualquer produto que cresce.

Projetar sistemas é aceitar que seu trabalho não termina quando o build passa. Ele continua na operação, na evolução e no impacto para as pessoas que usam, mantêm e dependem daquele software.

Quando você pensa assim, você muda:

o seu código, porque escreve com intenção e resiliência
suas prioridades, porque entende custo total e reversibilidade
sua colaboração, porque arquitetura vira um esforço de time

No fim, isso é o que permite criar valor sustentável. E, mais importante: preparar um produto para crescer sem transformar cada nova entrega em um risco.

Padrões de Arquitetura vs Padrões de Projeto

Programador Filosofo — Tue, 13 Jan 2026 19:42:41 +0000

Se você já se pegou em discussões do tipo "isso é padrão de projeto ou de arquitetura?" ou ouviu alguém chamar SOLID de padrão de projeto e microserviços de "padrão GoF moderno", saiba que isso é muito mais comum do que parece.

Na prática, a confusão não é só semântica. Quando misturamos os conceitos de padrões de arquitetura, padrões de projeto e princípios de design, fica mais difícil justificar decisões, ensinar o time e até diagnosticar os problemas de um sistema. Alguns autores resumem a diferença de forma bem direta: padrões de arquitetura cuidam da estrutura global do sistema, enquanto padrões de projeto tratam de soluções mais locais, em componentes ou partes específicas do código.

Este texto é um passeio organizado por esse terreno. A ideia é que você termine sabendo responder com segurança três perguntas:

O que é um padrão de arquitetura?
O que é um padrão de projeto?
Onde entram SOLID, GRASP e outras "siglas famosas" nessa história?

Mais do que decorar definições, o objetivo é criar um mapa mental que ajude no dia a dia: nas revisões de código, nas decisões de design, nas conversas com o time e, principalmente, na hora de evitar retrabalho.

Um mapa geral do "mundo dos padrões"

Antes de separar as coisas, vale montar um panorama.

De forma simplificada, o ecossistema de conceitos costuma ser organizado em camadas. Em um nível mais alto, estão os estilos e padrões de arquitetura, que falam de como o sistema se estrutura como um todo. Em um nível mais próximo do código, aparecem os padrões de projeto, lidando com a forma como classes e objetos colaboram para resolver problemas recorrentes. Atravessando tudo isso, aparecem princípios como SOLID e as orientações do GRASP, que funcionam como critérios de qualidade para avaliar se aquele design está saudável.

Você pode imaginar assim:

estilos e padrões de arquitetura respondem a perguntas do tipo "como vamos organizar o sistema inteiro?";
padrões de projeto respondem a perguntas como "qual estrutura de classes faz mais sentido para resolver esse problema específico?";
princípios de design ajudam a avaliar se a resposta que você encontrou é flexível, compreensível e fácil de evoluir.

Com esse mapa na cabeça, fica bem mais fácil entender o papel de cada peça.

Padrões de arquitetura: o esqueleto do sistema

Padrões de arquitetura são soluções consolidadas para problemas recorrentes de organização de sistemas. Eles definem como o software é dividido em partes maiores, quais responsabilidades cada parte assume e como essas partes se comunicam.

Quando falamos em arquitetura em camadas, MVC, microservices ou arquiteturas orientadas a eventos, estamos discutindo esse tipo de padrão. Não é só um detalhe de código; é a forma como o sistema se apresenta "de longe".

Um exemplo bem conhecido é a arquitetura em camadas, também chamada de layered ou N-tier. Nela, o sistema costuma ser organizado em blocos como interface de usuário ou APIs, camada de aplicação ou serviços, camada de domínio com as regras de negócio e camada de infraestrutura com banco de dados e integrações. Essa forma de organização aparece em livros, tutoriais e frameworks exatamente porque facilita a separação de responsabilidades, melhora a testabilidade e deixa mais claro "onde cada coisa deveria estar".

Outro exemplo clássico é o MVC, que separa Model, View e Controller e é usado desde frameworks web até aplicações desktop e mobile. O foco é manter a lógica de apresentação e a lógica de domínio em lugares distintos, favorecendo reuso e manutenibilidade. Em variações modernas, como o MVVM, esse princípio de separar visual, comportamento e dados continua, só muda a forma de organizar os papéis.

Microservices entram no jogo como um padrão de arquitetura mais avançado. Em vez de um único sistema grande, a aplicação é composta de vários serviços pequenos, cada um focado em uma capacidade de negócio e implantado de forma independente. Isso permite escalar partes específicas do sistema, dar mais autonomia para equipes e isolar domínios, mas cobra um preço alto em complexidade operacional, observabilidade, comunicação entre serviços e governança. É por isso que muitos autores insistem que microserviços não são uma "evolução natural" do monolito, e sim uma escolha que só vale a pena em determinados contextos. (GeeksforGeeks)

Por fim, vale mencionar o DDD (Domain Driven Design). Ele combina conceitos de modelagem de domínio com padrões arquiteturais e padrões táticos. Bounded contexts, entidades, value objects, agregados e repositórios são exemplos de elementos que aparecem com frequência em abordagens baseadas em DDD. Em muitos projetos, DDD vira quase um "guarda-chuva de arquitetura" que orienta como o sistema será dividido, nomeado e organizado em torno do negócio.

Em resumo: padrões de arquitetura lidam com decisões que mudam o desenho do sistema como um todo. Eles não são neutros; escolher um ou outro impacta performance, segurança, organização do time e até a forma como as regras de negócio são implementadas.

Padrões de projeto: soluções recorrentes dentro do código

Se a arquitetura é o esqueleto, os padrões de projeto são os movimentos e articulações que fazem o sistema funcionar de forma fluida.

Padrões de projeto surgiram como uma forma de documentar soluções recorrentes em design orientado a objetos. A referência mais famosa é o livro "Design Patterns: Elements of Reusable Object-Oriented Software", dos autores conhecidos como Gang of Four, que catalogou 23 padrões. Esses padrões foram organizados em três grupos principais: padrões criacionais, estruturais e comportamentais.

A grande ideia aqui não é "encher o sistema de padrões", e sim ter um vocabulário e um conjunto de soluções prontas para problemas muito comuns. Quando alguém diz que resolveu um problema com Strategy, por exemplo, está dizendo que encapsulou algoritmos em objetos intercambiáveis, permitindo variar o comportamento sem encher o código de condicionais. Quando alguém fala que criou uma Facade, está dizendo que colocou na frente de um subsistema complexo uma interface mais simples para quem consome.

O ponto interessante é o escopo. Autores que comparam padrões de arquitetura e de projeto são bastante claros em dizer que design patterns atuam em partes específicas do código, em componentes, enquanto architectural patterns tratam de decisões que impactam o sistema inteiro ou grandes subsistemas.

Imagine que você tem uma arquitetura em camadas definida. Essa arquitetura não diz exatamente como as classes dentro da camada de domínio vão se relacionar. É aí que padrões como Strategy, State, Observer, Factory Method, Adapter, entre outros, entram em cena para resolver problemas pontuais: variação de comportamento, acoplamento com bibliotecas externas, criação de objetos complexos, observação de eventos e assim por diante.

Padrões de projeto são, portanto, ferramentas para refinar uma arquitetura já escolhida. Eles funcionam melhor quando são usados com critério, em resposta a problemas reais, e não como um carimbo a ser aplicado a qualquer custo.

SOLID, GRASP e outros princípios: o "código de conduta" do design

Aqui aparece uma das confusões mais frequentes: tratar SOLID e GRASP como se fossem padrões de projeto.

SOLID é um acrônimo para cinco princípios de design orientado a objetos, propostos por Robert C. Martin, com a intenção de tornar o código mais compreensível, flexível e fácil de manter. Esses princípios estão relacionados a responsabilidade única, abertura para extensão, substituição correta de tipos, segregação de interfaces e inversão de dependência.

GRASP, por sua vez, é um conjunto de nove princípios de atribuição de responsabilidades em objetos, descritos por Craig Larman. Entre eles estão ideias como Information Expert, Low Coupling, High Cohesion, Controller, Creator, Polymorphism, Protected Variations e Pure Fabrication. A intenção é orientar como distribuir responsabilidades entre classes de forma que o projeto permaneça coeso, pouco acoplado e resistente a mudanças.

Repare que, no caso de SOLID e GRASP, não se trata de "estruturas prontas" como Strategy ou MVC, e sim de critérios para avaliar se a solução que você escolheu é boa. Em outras palavras, princípios como esses funcionam como um código de conduta do design. Eles ajudam a decidir se faz sentido colocar determinada lógica em uma classe, se a interface não está grande demais, se o acoplamento entre módulos não ficou excessivo.

Design patterns e princípios se relacionam, mas não competem. Um padrão como Strategy, por exemplo, ajuda a cumprir o princípio de aberto para extensão e fechado para modificação, que faz parte do SOLID. Da mesma forma, aplicar Observer com cuidado pode reforçar baixa acoplamento e alta coesão, conceitos centrais em GRASP.

Por isso é impreciso dizer que SOLID é "padrão de projeto". É mais correto dizer que você usou Strategy, por exemplo, de um jeito que respeita os princípios SOLID e GRASP.

Como tudo se encaixa em um projeto real

Um jeito prático de fixar essa diferença é imaginar uma situação concreta.

Suponha que você esteja criando um sistema de gestão de contratos. A primeira leva de decisões envolve arquitetura. Você decide que o sistema será inicialmente um monolito modular, organizado em camadas claras: uma API para entrada de requisições, uma camada de aplicação para orquestrar casos de uso, uma camada de domínio modelando contratos, apólices e cálculos, e uma camada de infraestrutura responsável por banco de dados e integrações externas. Nessa etapa, você está escolhendo padrões de arquitetura, talvez combinando camadas com alguns elementos de DDD.

Depois que o esqueleto está montado, aparecem problemas mais pontuais. Por exemplo, o cálculo do valor do contrato pode variar de acordo com o tipo de cliente, o produto e a vigência. Você quer evitar encher o código com condicionais. Aqui, um padrão de projeto como Strategy pode encaixar bem, encapsulando algoritmos de cálculo em classes diferentes e permitindo escolher a estratégia correta em tempo de execução. Em outro ponto do sistema, você quer esconder a complexidade de várias chamadas externas por trás de uma interface mais simples. Isso cheira a uma Facade.

Enquanto escolhe esses padrões, você avalia se o design está saudável usando princípios como SOLID e GRASP. Se uma classe de serviço começa a acumular casos de uso demais, talvez esteja violando responsabilidade única. Se uma camada depende diretamente de detalhes de infraestrutura, talvez você precise aplicar inversão de dependência. Se um módulo conhece detalhes internos de outro, pode estar faltando baixo acoplamento.

Perceba a sequência: primeiro a arquitetura dá o desenho macro. Dentro desse desenho, os padrões de projeto refinam as soluções locais. Em todas essas decisões, princípios como SOLID e GRASP funcionam como régua de qualidade.

Armadilhas comuns quando se fala de padrões

Conhecer os conceitos é apenas metade do caminho. A outra metade é evitar alguns erros bastante comuns.

Um deles é tratar padrão como objetivo em si. Às vezes, alguém decide que "precisa usar mais padrões" e começa a encaixar Strategy, Factory, Builder e por aí vai em lugares onde uma função simples resolveria o problema. O resultado é um código cheio de indireções desnecessárias, difícil de entender e de manter. Autores que documentam design patterns reforçam que eles são respostas a problemas recorrentes, não uma lista de coisas que você "tem que usar" para parecer profissional.

Outra armadilha é confundir framework com padrão. Usar um framework MVC não garante que a sua arquitetura esteja bem desenhada. É perfeitamente possível ter um "MVC" onde a View conhece detalhes de banco de dados ou onde o Controller faz todas as regras de negócio. O mesmo vale para microserviços: adotar um framework que facilita criar serviços pequenos não resolve, por si, problemas de definição de limites de contexto, orquestração e dados compartilhados.

Existe ainda o risco de tratar SOLID como religião. Quando cada princípio é aplicado de forma dogmática, surgem classes minúsculas demais, excesso de interfaces sem necessidade, camadas a mais só para cumprir "inversão de dependência" e um número de arquivos desproporcional ao valor entregue. Bons materiais sobre SOLID insistem em algo importante: os princípios são guias para evitar mau design, não regras inflexíveis.

O mesmo vale para GRASP. A busca por baixa acoplamento e alta coesão não significa sair quebrando o sistema em dezenas de serviços ou classes por reflexo. A ideia é encontrar pontos de variação e de responsabilidade que façam sentido, mantendo o desenho compreensível para humanos reais que vão ler e modificar aquele código.

No fundo, o problema central é o mesmo: esquecer que padrões e princípios são ferramentas a serviço de objetivos concretos, como clareza, robustez e facilidade de mudança.

Conclusão e próximos passos

A diferença entre padrões de arquitetura e padrões de projeto fica bem mais nítida quando você a enxerga pelo escopo da decisão.

Arquitetura lida com o desenho global do sistema. É na arquitetura que você decide se terá um monolito modular ou microserviços, se vai usar camadas tradicionais, hexagonal, orientada a eventos ou outra variação, e como as fronteiras entre contextos de negócio serão estabelecidas. Essas decisões impactam o trabalho do time inteiro e costumam ser difíceis de mudar depois de certo ponto.

Padrões de projeto atuam dentro desse desenho, cuidando de problemas recorrentes na colaboração entre classes e objetos: variação de comportamento, encapsulamento de dependências externas, criação de objetos complexos, notificação de múltiplos interessados e assim por diante. O catálogo de 23 padrões documentado pelo Gang of Four continua sendo uma base sólida e, até hoje, é referência em praticamente todos os cursos e materiais sobre design patterns.

Princípios como SOLID e GRASP, por fim, não são padrões no sentido de "estruturas prontas", e sim lentes pelas quais você avalia se o design está saudável. Eles ajudam a evitar classes gigantes, acoplamentos desnecessários, interfaces inchadas e decisões que dificultam a evolução. Funcionam bem justamente porque não estão presos a uma linguagem ou framework específico.

Se for para resumir em uma única ideia: quanto mais você conhece esses padrões e princípios, menos energia gasta inventando soluções para problemas que já foram estudados, documentados e refinados por outros desenvolvedores antes de você. Sobra mais espaço mental para o que realmente importa, que é modelar bem o domínio do seu sistema e entregar valor de negócio com qualidade técnica.