Arquitetura moderna no Salesforce: muito além do projeto inicial

E aí, pessoal? Vamos juntos em mais uma das maneiras que encontrei de estudar? Boas-vindas a mais uma das minhas análises, nas quais eu trago para a minha realidade em Salesforce os temas que estudo no dia a dia.

Este tema, em particular, é muito legal porque ontem mesmo tive uma conversa com um cliente sobre arquitetura, modularização e planejamento.

Então, hoje eu vou falar sobre o que estudei na última aula: Arquitetura de Software Moderna. O objetivo é muito claro: quebrar aquela velha ilusão de que arquitetura de software é só um desenho feito no início do projeto e depois esquecido em uma gaveta, junto com tudo que já desenvolvemos na org.

Principalmente quando a gente fala do ecossistema Salesforce, né? A arquitetura moderna é algo vivo. Ela respira, muda e evolui junto com o próprio produto. Então se ajeita aí para esta leitura, porque vamos entender como essa prática contínua funciona de ponta a ponta.

Vou cobrir seis pontos principais: arquitetura moderna no Salesforce, arquitetura intencional, engenharia de software ágil, arquitetura evolutiva, arquitetura emergente e, por fim, toda essa teoria aplicada a um exemplo prático.

1. Arquitetura moderna no Salesforce: muito além do projeto inicial

Olha só, a grande virada de chave no desenvolvimento de hoje é entender que a arquitetura definitivamente não para quando a primeira linha de código começa a ser escrita. Ela é uma prática diária. As decisões precisam se adaptar o tempo todo conforme o produto ganha maturidade.

Para facilitar e nos guiar nessa jornada, a própria Salesforce organiza o seu framework de boas práticas, o Salesforce Well-Architected Framework, em soluções que precisam ter três características:

• Trusted: soluções confiáveis, que protegem o negócio e as pessoas.
• Easy: soluções fáceis de usar e capazes de entregar valor rapidamente.
• Adaptable: soluções que evoluem junto com as mudanças do negócio.

São esses três pilares que norteiam todo o ecossistema.

2. Arquitetura intencional: decidir de forma consciente

É agora que a gente precisa parar de simplesmente tentar fazer funcionar a qualquer custo. Sabe aquele lance de apagar incêndio o tempo todo? Que sentimento horroroso na vida de quem desenvolve. Na moralzinha: tem que acabar.

A arquitetura intencional é construir com consciência total. É tomar decisões claras e deliberadas para que a solução final se encaixe no negócio de hoje, mas sem ignorar a manutenção e a evolução de amanhã.

Lembra que mencionei as soluções Easy? Uma solução intencional entrega valor rapidamente no presente, mas não fecha as portas para o futuro.

Na prática de uma equipe ágil, quando chega aquela demanda nova e urgente, a arquitetura intencional exige que a gente respire fundo e faça uma pergunta que vale mais do que barras de ouro:

Esta é a primeira coisa que ensino para meus mentorados: verifique se já existe algo na org que atende à necessidade ou que pode ser adaptado. Só crie algo novo se realmente não existir nada que possa ajudar.

É preciso fazer um discovery na org. Se existir uma documentação completa, vá atrás da informação. Entenda o cenário primeiro e só depois pense em desenvolver algo novo.

Antes de criar vários objetos customizados do zero, a gente precisa avaliar os recursos padrão. Antes de escrever linha após linha em Apex, precisamos testar se um simples Flow não resolveria o problema com muito mais elegância.

É sempre uma escolha equilibrada entre configuração, código, automação e segurança. Isso nos traz a um mantra que todo mundo que desenvolve deveria anotar em um post-it e colar na tela:

Esse é literalmente o filtro definitivo para qualquer decisão que a gente toma logo na largada.

3. Engenharia de software ágil: entregar valor de forma incremental

Aqui o nosso foco muda um pouquinho. A gente tira o peso daquele planejamento inicial gigante e passa a focar também na execução: entregar valor aos poucos, de forma incremental, sprint a sprint.

E como existe mal-entendido no mercado sobre isso, né? Agilidade não significa jogar arquitetura pela janela e sair codando. Pelo contrário, é fazer arquitetura suficiente para entregar valor real, aprender com os feedbacks e evoluir a solução pouco a pouco.

Quando as equipes confundem ser ágil com improvisar e não planejar, o resultado é um caos absoluto na org. Sabe aqueles Flows gigantescos que parecem uma teia de aranha? Campos duplicados para todo lado? Objetos customizados que não servem para nada? Triggers brigando com Flows para ver quem executa primeiro? Integrações sem nenhum tipo de log?

Ou pior: a demanda é entregue e até atende ao requisito, mas o cliente volta pedindo milhões de pequenos ajustes. O resultado final é um pesadelo de manutenção. Fica praticamente impossível sustentar a solução a longo prazo.

A grande sacada é encontrar o equilíbrio entre pensar no amanhã e resolver o problema de hoje.

4. Arquitetura evolutiva: a arte de se preparar para mudanças

O objetivo principal aqui é quase criar um escudo para o sistema. É proteger o software contra o futuro. Porque, vamos ser sinceros, a única verdade absoluta no desenvolvimento é que tudo vai mudar.

Requisitos mudam, usuários pedem coisas novas e as prioridades da empresa dão um giro de 180°. Uma arquitetura evolutiva abraça isso como regra, não como uma dor de cabeça esporádica.

Se o sistema é muito rígido, qualquer pequena alteração vira um retrabalho enorme. Com um design flexível, o sistema acompanha as mudanças da empresa sem que a gente precise derrubar tudo e construir do zero.

No dia a dia do Salesforce, a gente constrói essa resiliência por meio de blocos claros:

• Modularidade: Flows menores no lugar de um fluxo gigantesco, além de serviços Apex e LWCs reutilizáveis.
• Configurabilidade: Custom Metadata e Custom Settings para alterar regras sem mexer no código.
• Reuso: Subflows e serviços compartilhados para evitar duplicações.
• Observabilidade: logs e rastreabilidade para entender o comportamento da solução.

Lembre-se: modularizar é como montar um LEGO que está sempre pronto para virar outra coisa.

Tenha sempre em mente que a única constante no nosso universo é a mudança.

5. Arquitetura emergente: aprender com a realidade

É aqui que a mágica de observar a vida real acontece. A gente passa a absorver conhecimento diretamente de um sistema que já está rodando em produção e suando a camisa.

A beleza da arquitetura emergente é aceitar que a gente não terá todas as respostas no primeiro dia. E está tudo bem.

A arquitetura surge gradualmente. A gente começa simples e, à medida que as pessoas usam o sistema e padrões de repetição aparecem ao longo das sprints, as necessidades ficam mais claras. A equipe reorganiza as peças com base no uso real.

Mas atenção, porque existe uma linha muito tênue entre um sistema que emerge e uma bagunça completa.

De um lado, a arquitetura emergente aprende de verdade com o uso. A equipe refatora o código quando percebe um padrão, documenta o motivo das decisões e evolui com uma governança forte.

Do outro lado está a bagunça: construir sem direção, nunca revisar os processos, esquecer por que as coisas foram criadas e gerar um ciclo infinito de retrabalho e frustração.

Não é jogar o código lá e torcer pelo melhor. É um amadurecimento controlado e seguro.

6. A teoria na prática: aplicando os quatro conceitos

Chegou a hora da verdade. Vamos pegar essa teoria e ver os quatro conceitos funcionando juntos para resolver um problema do mundo real.

Imagine o seguinte cenário chegando à equipe amanhã: precisamos de uma regra para impedir que um Case seja fechado quando faltarem documentos obrigatórios.

Parece simples, né? Mas vamos ver como resolver isso do jeito certo:

1. Intencional: não saímos criando código às cegas. Analisamos as regras existentes, identificamos a quais tipos de Case a validação se aplica e verificamos se já existe algo parecido. Também avaliamos se uma solução declarativa atende ou se realmente precisamos partir para o código.
2. Ágil: entregamos rapidamente uma primeira versão simples da regra para colher o feedback dos usuários.
3. Evolutiva: não deixamos a regra chumbada no sistema. Podemos usar, por exemplo, Custom Metadata para permitir que os documentos obrigatórios sejam alterados sem modificar a lógica principal.
4. Emergente: se, algumas semanas depois, a equipe de vendas pedir o mesmo bloqueio em Opportunities, refatoramos a solução e transformamos a lógica em um serviço centralizado e reutilizável.

Para encerrar, fica aqui a síntese de tudo que cobrimos:

Agora eu deixo uma provocação para você: quais hábitos você precisa criar para se tornar uma pessoa profissional capaz de visualizar o amanhã, e não apenas a solução do problema de hoje?

Não sou dona da verdade. Se você não concorda ou tem algo para contribuir, compartilhe sua perspectiva comigo.

Para acompanhar conteúdo técnico gratuito todos os dias, acesse também o OmniStudio 365.