Artigos sobre architecture
29 artigos de Felipe Guedes sobre architecture: System Design, arquitetura, engenharia full stack, auditoria e IA em produção.
- As doze perguntas que faço em toda revisão de arquiteturaAs mesmas doze perguntas, na mesma ordem, em todo sistema. Elas encontram a maior parte do que importa em um dia.
- O quadro branco é onde o sistema é construído de verdadeAs decisões que doem depois são tomadas na primeira hora, antes de qualquer código. O que eu desenho e por quê.
- Onde as regras de negócio deveriam morar, e onde elas acabamA regra é escrita uma vez na especificação e cinco vezes no código. Como ela se espalha, e como trazê-la de volta para casa.
- As fronteiras são o produtoFuncionalidades vêm e vão. As fronteiras que você traça entre elas são o que você ainda vai estar pagando daqui a cinco anos.
- Strangler fig, feito com honestidadeO padrão funciona. O que mata é fingir que o sistema antigo vai morrer sozinho. Ele não vai.
- Por que a maioria dos microsserviços deveria ter sido móduloA fronteira de rede é um imposto permanente. Quatro razões para um serviço merecê-la, e os sinais de que o seu deveria ser módulo.
- Diga não à reescritaA reescrita promete começo limpo e entrega um segundo sistema correndo atrás do primeiro. Cinco perguntas antes de aprovar.
- Eventos de domínio e notificações não são a mesma coisaUm é um fato que o negócio se importa. O outro é um cutucão. Confundir os dois é como sistemas orientados a eventos apodrecem.
- Projetando para a exclusãoTodo sistema sabe criar um registro. Poucos sabem excluir direito. Projete a exclusão primeiro e o resto fica mais simples.
- Multi-tenancy: a decisão que você não consegue desfazerSchema compartilhado, schema por tenant ou banco por tenant: cada um tem suas dores, e trocar depois significa migrar tudo.
- A armadilha da biblioteca compartilhadaO pacote criado para evitar duplicação costuma ser o acoplamento mais forte do sistema. Como reconhecer, e o que fazer no lugar.
- Registros de decisão de arquitetura que alguém realmente lêA maioria dos ADRs é escrita uma vez e nunca mais aberta. Aqui está o formato e a disciplina que os fazem sobreviver.
- O monólito modular na práticaUma unidade de deploy, fronteiras internas rígidas. Como fica numa base TypeScript real, e onde os times trapaceiam.
- Reversibilidade como objetivo de arquiteturaA melhor decisão de arquitetura é a que dá para desfazer em um sprint. Otimize para isso antes de otimizar para qualquer outra coisa.
- O bug está sempre na fronteiraDentro de um módulo, o código é consistente consigo mesmo. Os bugs moram onde duas coisas com premissas diferentes se encontram.
- Lendo código legado como um arqueólogoCódigo legado não é código ruim. É um registro de decisões sob pressão. Aprenda a ler as camadas antes de cavar.
- Agentes também precisam de fronteirasUm agente é um loop com permissões. Toda regra que aplico a serviços vale para ele, com um raio de dano maior.
- A rota de API que virou um monólitoComeçou como um handler. Dois anos depois é um arquivo de 900 linhas que ninguém ousa tocar. Veja como evitar isso.
- Cache é uma decisão de consistência disfarçadaCache é uma cópia, e toda cópia te obriga a decidir o quão desatualizado o usuário pode ver o mundo.
- Contratos antes do códigoEscreva a interface, o schema e os casos de falha antes da primeira linha de implementação. É a revisão de design mais barata que existe.
- Arquitetura hexagonal sem a cerimôniaPorts and adapters é uma boa ideia enterrada debaixo de uma pilha de pastas. Fique com a ideia, jogue fora a pilha.
- Server Components mudam onde fica a fronteiraA fronteira antiga era a API. A nova é uma diretiva no topo do arquivo. A maioria dos times ainda não percebeu.
- Quanto custa de verdade um serviço novoO código é a parte barata. Esta é a fatura que vem junto com cada caixinha que você adiciona ao diagrama.
- O modelo vai mudar. A interface não deveria.Projete a fronteira em volta do modelo para que trocar provedor, versão ou prompt seja mudança de config, não reescrita.
- O banco de dados não é sua camada de integraçãoDois sistemas que compartilham um banco são um sistema com dois pipelines de deploy e nenhum contrato. Veja como sair dessa.
- O problema não é o monolito, é o acoplamentoQuebrar um monolito emaranhado em serviços te dá um sistema distribuído emaranhado. Resolva o acoplamento primeiro.
- Versionar uma API é uma relação, não um númeroA versão na URL é a parte menos importante. O que importa é quem depende de você e o que você deve a essas pessoas.
- A lei de Conway é uma ferramenta, não uma maldiçãoSeu sistema vai espelhar o organograma, goste você ou não. Então desenhe o organograma de propósito.
- Dívida técnica é um empréstimo, e todo empréstimo tem um nomeA dívida não é o atalho. É o atalho sem dono, sem prazo e sem data de pagamento. Conserte a metáfora e o backlog anda.