Padrões de arquitetura

Saiba mais sobre um recurso e otimização de custo bem construídos → Suas responsabilidades de otimização

Esta página fornece orientação de padrão abrangente para preocupações arquitetônicas, incluindo unidades funcionais, separação de preocupações, gerenciamento de estado, gerenciamento de API e mensagens. Esses padrões moldam o sucesso da solução de longo prazo por meio de decisões de design deliberadas sobre limites de serviço, padrões de acesso a dados e responsabilidades de componente.

Padrões

Onde procurar	Qual é a boa aparência
Classes do Apex	✅ As classes de serviço seguem o princípio de responsabilidade única com nomes que indicam claramente a finalidade (AccountService, OrderProcessor, InventoryManager). Cada classe de serviço se concentra em um domínio ou recurso de negócios. Os métodos em classes de serviço têm responsabilidades únicas e focadas em menos de 20 linhas.
Acionadores	✅ Os acionadores são delegados a classes de manipulador em vez de conter a lógica de negócios diretamente. Padrão do manipulador do acionador usado de modo consistente com nomes de método claros por contexto (handleBeforeInsert, handleAfterUpdate). As classes de manipulador organizam a lógica por evento de acionador com responsabilidades únicas por método.
Componentes da Web Lightning	✅ Os componentes seguem o princípio de responsabilidade única com interfaces de suporte claras para configuração. Cada LWC se concentra em uma preocupação de UI (exibição de dados, entrada do usuário, navegação). Componentes projetados para composição, não implementações monolíticas.
Camada de serviço	✅ As classes de serviço encapsulam a lógica de negócios independentemente do ponto de entrada (acionador, API, Fluxo, lote). A mesma classe de serviço lida com vários contextos de invocação sem duplicação. A camada de serviço separa regras de negócios de preocupações de apresentação e acesso a dados.
Componentes reutilizáveis	✅ Componentes projetados para reutilização em vários projetos e equipes. O comportamento conduzido por configuração usando tipos de metadados personalizados habilita alterações de comportamento sem implantação de código. Ações invocáveis expõem a lógica do Apex como blocos de construção declarativos utilizáveis a partir de Flow e orquestração externa.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Classe de Deus	⚡️ Evite acumular responsabilidade excessiva em uma única classe. Divida classes grandes (>500 linhas) em classes focadas com responsabilidades únicas. Reorganize as classes quando elas lidarem com várias preocupações não relacionadas (o OrderProcessor não deve também lidar com o envio e o relatório de emails).
Preocupações mistas	⚡️ Evite misturar lógica do acionador, regras de negócios e acesso a dados em classes únicas. Separe a lógica de apresentação da lógica de negócios em controladores. Mantenha as preocupações de integração separadas da lógica de domínio principal.
Lógica do acionador em acionadores	⚡️ Evite integrar lógica de negócios diretamente em arquivos de acionador. Nunca use mais de 300 acionadores de linha com condições aninhadas. Sempre delegue para classes de manipulador com organização de método clara pelo contexto do acionador.

Padrões

Onde procurar	Qual é a boa aparência
Lógica de negócios	✅ Regras de negócios centralizadas em classes de serviço, não espalhadas entre acionadores, controladores e classes em lote. As classes de domínio encapsulam o comportamento no nível do registro (validação, padrões, valores derivados) de modo consistente, independentemente de como os registros entram no sistema. Lógica reutilizada por meio da camada de serviço em vez de duplicada entre pontos de entrada.
Acesso a dados	✅ Acesso a dados extraído atrás das classes de padrão de repositório ou seletor. Consultas SOQL centralizadas em classes seletoras (AccountSelector, OpportunitySelector) garantindo listas de campos consistentes e cláusulas WHERE. O padrão de repositório permite testar com origens de dados simuladas sem alterar a lógica de negócios.
Interface de contratos	✅ Os componentes se comunicam por meio de interfaces explícitas, em vez de detalhes de implementação. As interfaces do Apex definem contratos entre camadas. A configuração de metadados personalizados define limites de comportamento. Os Eventos de plataforma fornecem contratos de mensagens entre produtores e consumidores.
Limites do módulo	✅ Os contextos limitados definem limites de propriedade claros para modelos de dados e regras de negócios. Cada módulo possui seus dados, automação e lógica de negócios. Os módulos interagem por meio de APIs definidas, em vez de compartilhar objetos de banco de dados diretamente. A documentação identifica claramente qual equipe possui quais objetos e serviços.
Fluxo de dependência	✅ Dependências fluem em uma direção (presentação → negócios → dados). A lógica de negócios principal depende de nada externo, permitindo a evolução independente. As preocupações de infraestrutura (log, armazenamento em cache, APIs externas) dependem da lógica de negócios por meio de interfaces, não vice-versa.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Duplicação lógica	⚡️ Evite duplicar a lógica de negócios entre acionadores, pontos de extremidade da API e classes em lote. Centralize na camada de serviço e reutilize entre pontos de entrada. Sempre que a mesma regra de negócios aparecer em várias classes, extraia para o serviço compartilhado.
Acesso a dados espalhado	Evite consultas SOQL espalhadas por classes de acionador, controlador e lote com listas de campos inconsistentes e cláusulas WHERE. Centralize consultas em classes seletoras garantindo padrões consistentes e habilitando a otimização de LDV em um só local.
Lógica de negócios em acionadores	⚡️ Evite regras de validação, cálculos de campo e orquestração de fluxo de trabalho integrados diretamente ao código do acionador. Mover para classes de serviço ou classes de domínio. Mantenha os acionadores finos, focando apenas a delegação a manipuladores adequados.
Lógica de negócios em controladores	⚡️ Evite cálculos complexos, validação ou manipulação de dados em métodos de controlador do Aura/LWC. Os controladores devem orquestrar chamadas para a camada de serviço, não implementar regras de negócios diretamente.
Dependências circulares	Evite pacotes ou classes com dependências circulares em que A depende de B e B depende de A. Resolva extraindo preocupações compartilhadas para um módulo separado, inverter a direção da dependência ou usando a comunicação conduzida por evento para interromper o acoplamento.

Padrões

Onde procurar	Qual é a boa aparência
Cache da plataforma (partição da organização)	✅ Dados de referência acessados com frequência armazenados em cache na partição da organização, incluindo pesquisas de metadados personalizados, valores da lista de opções, configurações de configuração e resultados calculados de operações caras. TTL padrão configurado com base na volatilidade de dados (horas para alteração mensal de dados de referência, minutos para configuração atualizada com frequência). A estratégia de cache da chave evita colisões entre diferentes tipos de dados.
Cache da plataforma (partição da sessão)	✅ Preferências específicas do usuário, dados de personalização calculados e estado no escopo da sessão armazenados no cache da sessão. O cache da sessão não é usado para dados que devem ser compartilhados entre usuários. A estratégia de invalidação de cache lida com as atualizações de preferências do usuário adequadamente.
Lightning Data Service	✅ O LDS fornece armazenamento automático de registro no lado do cliente para Componentes da Web Lightning. Operações CRUD padrão usam LDS em vez de controladores do Apex personalizados. O LDS elimina as viagens de ida e volta do servidor redundantes e fornece atualizações de UI otimizadas. Os componentes aproveitam o cache compartilhado do LDS em toda a página.
Tipo de metadados personalizados	✅ Regras de configuração e comportamento armazenadas em tipos de metadados personalizados em vez de embutidas em código em classes. Metadados personalizados implantáveis em ambientes por meio de conjuntos de alterações ou desenvolvimento conduzido por origem. Alterações em metadados personalizados não exigem um ciclo de implantação completo. Armazene em cache consultas de metadados personalizadas no Cache da plataforma para obter desempenho.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Consulta em Loop	⚡️ Evite executar SOQL em loops de iteração. Consulte todos os registros necessários em uma única instrução SOQL fora dos loops. Organize os resultados em Mapas por ID pai para pesquisa durante a iteração. Esse é o único antipadrão mais comum do Salesforce.
Pesquisas repetitivas	⚡️ Evite consultar os mesmos metadados personalizados, configurações personalizadas ou consultar dados várias vezes por transação. Consulta uma vez, armazenamento em cache da plataforma ou variável estática da transação, reutilização entre transações.
Estratégia de cache ausente	⚡️ Evite consultar repetidamente dados de referência acessados com frequência sem armazenamento em cache. Implemente o Cache da plataforma para metadados personalizados, configuração e resultados calculados. Defina o TTL adequado com base na volatilidade dos dados.
Cache sem invalidação	⚡️ Evite armazenar dados em cache sem considerar a estratégia de invalidação. Defina o TTL de cache adequado para a frequência de atualização. Implemente a limpeza de cache manual quando os dados de origem mudarem se a TTL sozinha for insuficiente.
Estado da sessão não gerenciada	⚡️ Evite presumir que o estado da sessão persista entre as navegações da página sem verificação. Os componentes do Lightning devem lidar com a atualização de estado no carregamento da página. Use o Lightning Data Service para sincronização automática de estado.

Padrões

Onde procurar	Qual é a boa aparência
Planejamento de arquitetura de soluções	✅ O planejamento da arquitetura ocorre antes de um investimento de construção significativo, incluindo análise de requisitos (funcional e não funcional), análise de limite do regulador para volumes de dados esperados, seleção de padrão adequada aos requisitos e design de componente definindo os principais componentes e interfaces.
Seleção de padrão de design	✅ Padrões de design do Salesforce comprovados aplicados de modo consistente: Padrão da camada de serviço para reutilização da lógica de negócios, Padrão do repositório/seletor para abstração de acesso a dados, Padrão de estratégia para algoritmos intercambiáveis, Padrão de domínio para comportamento em nível de registro, Padrão do manipulador do acionador para organização de acionador consistente.
Registros de Decisão de Arquitetura	✅ Decisões arquitetônicas significativas documentadas em ADRs armazenados no controle de versão. Os ADRs capturam o contexto (acionadores de negócios, restrições técnicas), a decisão (o que foi escolhido), as alternativas consideradas (por que outras foram rejeitadas) e as consequências (negócios, débito técnico, acionadores de revisita).
Construir vs. comprar avaliação	✅ A avaliação do AppExchange precede decisões de desenvolvimento personalizadas usando a análise de custo total de propriedade. Os critérios de avaliação incluem valor estratégico (diferenciador competitivo vs. commodity), comparação de TCO (efeito de construção, custos de manutenção, custos de atualização), complexidade da integração e custo de saída se a solução for inadequada.
Análise de limite do governador	✅ O planejamento arquitetônico identifica qual controlador limita mais o design de restrições com base nos volumes de dados esperados e nos padrões de transação. Transações projetadas para consumir menos de 80% de qualquer limite de controlador único sob condições de pico. Margem criada para crescimento, recursos futuros e padrões de uso inesperados.
Avaliação de riscos	✅ Riscos técnicos identificados para abordagens arquitetônicas que promovem limites de plataforma. Estratégias de mitigação definidas para cada risco significativo. O trabalho de prototipagem ou prova de conceito valida pressuposições para abordagens técnicas de alto risco antes do compromisso de criação completa.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Sem planejamento	⚡️ Evite começar a criar sem analisar volumes de dados, implicações de limite do regulador ou seleção de padrão. O workshop de planejamento de arquitetura deve identificar as principais restrições, selecionar padrões e validar em relação aos limites do regulador antes do início da criação.
Decisões não documentadas	⚡️ Evite decisões arquitetônicas tomadas em reuniões sem capturar contexto, fundamento, alternativas e consequências. Use Registros de decisão de arquitetura armazenados no controle de versão preservando o contexto de decisão para futuros membros da equipe.
Análise sem compilação vs. compra	Evite criar soluções personalizadas sem avaliação do AppExchange. Avalie os 3-5 principais pacotes relevantes antes do desenvolvimento personalizado. Compare o TCO, incluindo esforço de implementação, manutenção, custos de atualização e custos de saída.
Sub-Engenharia	⚡️ Evite projetar apenas para volumes de dados atuais sem projeção de crescimento. Projetar crescimento de dados em 2-3 anos. Projete padrões de consulta com seletividade validada em relação a volumes atuais de 5-10x. Crie margem arquitetônica para crescimento.

Padrões

Onde procurar	Qual é a boa aparência
Pacotes gerenciados de segunda geração (2GP)	✅ 2GP usado para novos pacotes gerenciados que exigem isolamento de namespace, distribuição AppExchange e proteção de IP. Fluxo de trabalho de desenvolvimento orientado por origem com desenvolvimento de aplicativo modular. Dependências de pacote gerenciadas explicitamente. Versões liberadas com controle de versões semântico.
Pacotes desbloqueados	✅ Pacotes desbloqueados usados para aplicativos corporativos internos que exigem modularidade sem restrições de namespace. Implantação independente de pacotes sem artefatos dependentes da organização. Dependências do pacote rastreadas para ordem de implementação adequada. Estratégia de controle de versão definida para pacotes internos.
Limites do módulo	✅ Limite os limites de propriedade definidos para cada pacote. Cada pacote possui seu modelo de dados, regras de negócios e automação. Os pacotes interagem por meio de interfaces definidas, em vez de acesso direto a objetos. A documentação identifica a propriedade do pacote e os contratos entre pacotes.