Leia sobre nossas agendas de atualização aqui.

As soluções compostables são ajustadas rapidamente e com maior estabilidade. Um sistema arquitetado para ser composível é criado em unidades significativas, ou blocos de construção, que podem operar perfeitamente entre si e podem ser trocados facilmente entre e fora de serviço. Criar capacidade de composição em um sistema permite que você apresente novos recursos ou remova o débito técnico refatorando ou remontando unidades individuais de um sistema. A capacidade de composição permite ciclos de entrega e versões mais rápidos e mais previsíveis, pois as equipes podem se concentrar em criar e entregar recursos significativos por meio de menores quantidades de alterações.

Os sistemas compostos permitem que as empresas adaptem-se mais rapidamente e com maior estabilidade, independentemente de o estímulo ser interno ou causado por fatores externos. A capacidade de composição ajuda os sistemas a serem mais resilientes e pode ajudar a tornar as soluções e os padrões arquitetônicos mais intencionais.

Você pode tornar suas soluções do Salesforce mais composíveis criando três hábitos importantes: separação de preocupações, interoperabilidade e capacidade de empacotamento. Abaixo, você pode ver o relacionamento desses hábitos de duas maneiras: para uma única unidade de em um sistema composível e entre várias unidades em um sistema composível.

Uma única unidade composta:

Um sistema composto:

Um conceito fundamental na engenharia de software e arquitetura de sistemas, a separação de preocupações implica identificar várias preocupações dentro de um sistema maior que pode ser separado em unidades modulares. Para realizar uma forte separação de preocupações em um sistema, é necessário criar unidades significativas para lógica de aplicativos e funções em todo o sistema. As unidades menores tornam mais fácil para as equipes de entrega e manutenção de aplicativos entenderem como e onde fazer alterações, com interrupções mínimas no sistema maior. As unidades menores também tornam mais claro como e onde focar o trabalho ao lidar com a débeda técnica e contribuem para a leitura geral do seu sistema.

Você pode criar uma melhor separação de preocupações em sua organização do Salesforce orientando-a para a funcionalidade de negócios e o estado de gerenciamento.

Para sistemas do Salesforce, a melhor abordagem para a separação de preocupações aplica uma perspectiva orientada para os negócios para identificar e organizar unidades modulares (ou recursos) no sistema. Isso é diferente de uma visualização focada em engenharia, que identifica unidades com base em sua função técnica. Uma perspectiva orientada para os negócios em separação de preocupações exige organizar o código e as personalizações em seu sistema com base no serviço que eles fornecem aos usuários comerciais e comerciais. Adotar essa abordagem não significa ignorar o potencial de funções técnicas redundantes ou duplicadas em um sistema. Em vez disso, isso significa que os serviços técnicos são mapeados claramente para um princípio de organização que seja, por fim, transparente para os negócios.

Orientar-se para as funcionalidades de negócios ajuda a garantir que as transferências entre a análise de negócios e as equipes de descoberta para as equipes de entrega sejam o mais simples possível. Se os criadores de aplicativo não tiverem ideia de onde suas unidades de trabalho serão mapeadas para sua arquitetura composível, você terá uma bagunça, não uma paisagem de aplicativo composível. Mapeamentos pouco claros entre o estado final exigido pela empresa e as unidades modulares em uma organização também aumentam as chances de equipes de desenvolvimento ou fornecedores criarem funções redundantes no sistema.

Considere o seguinte para orientar as unidades funcionais para a funcionalidade dos negócios:

• Comece com trabalhos a serem feitos. Concentre-se nos trabalhos a serem feitos (JTBD) dos usuários e na empresa em si. Iniciada por Tony Ulwick, a abordagem do JTBD se concentra na compreensão do "trabalho", ou verdadeiro propósito, que as pessoas estão tentando alcançar usando um produto ou serviço. É um nível mais alto de abstração do que as tarefas relacionadas ao papel dos usuários ou as etapas individuais em um processo de negócios. Por exemplo, tarefas como verificações de duplicados e validações de endereço podem se enquadrar em uma função de ordem superior de "estabelecer uma única visualização do cliente". Depois de ter uma ideia clara desses recursos de negócios de ordem superior, você pode começar a mapear partes do seu sistema para eles.
• Oriente-se às capacidades, não às estruturas de relatórios. A hierarquia interna de suas unidades de negócios não é um proxy para funcionalidades ou trabalhos significativos a serem feitos. A hierarquia interna de seus negócios tem impacto material em processos e estruturas de equipe (para não mencionar orçamentos). Essas são considerações logísticas importantes. Porém, as necessidades funcionais dos negócios operam em um nível mais alto de abstração do que a logística. Se você estiver criando um módulo para apresentar uma estrutura de relatórios em vez de uma função de ordem superior, esteja ciente de que talvez seja necessário realizar etapas adicionais para identificar como esse módulo se relaciona às funcionalidades de negócios.
• Seja iterativo. Comece fazendo parceria com a empresa para identificar qual funcionalidade poderia funcionar para um produto mínimo viável (MVP). Ao identificar uma funcionalidade, comece a criar esse MVP. Conforme você cria, identifique os processos, metadados e eventos ou mensagens que são centrais para a unidade funcional que você está criando. Identifique quaisquer processos, metadados e eventos ou mensagens que sejam dependências externas. À medida que unidades mais funcionais são projetadas, implemente o Gerenciamento de API e o Gerenciamento de dependência para criar unidades que funcionem bem umas com as outras (em vez de criar unidades isoladas).

A lista de padrões e antipadrões abaixo mostra qual é a orientação correta (e ruim) para funções de negócios em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas.

Para saber mais sobre as ferramentas disponíveis do Salesforce para ajudá-lo a se orientar melhor para as funcionalidades de negócios, consulte Ferramentas relevantes para composáveis.

O gerenciamento de estado se concentra na movimentação de informações em um sistema em vários pontos no tempo. O gerenciamento de estado eficaz permite que os aplicativos lidem com fluxos complexos de dados ou interações com um mínimo de resultados não planejados ou indeterminados. Gerenciar o estado em uma organização do Salesforce modular significa criar caminhos claros para fluxos de lógica dentro e entre unidades, bem como caminhos elegantes para comportamentos de execução não planejados. O gerenciamento de estado permite formar fluxos de lógica coerentes de unidades de aplicativo do Salesforce modulares. Na maioria dos casos, isso exige interoperabilidade para estruturar o fluxo de informações entre unidades.

Dificuldades no gerenciamento de estado entre unidades soltas geralmente levam ao desenvolvimento de aplicativos monolítico no Salesforce. Você pode ver isso em grandes "monofluxos", que são criados em uma tentativa de orquestrar um processo complexo em um fluxo singular. Outro exemplo são classes Apex maciças, que orquestram processos complexos por meio de código espaguete, ou uma longa série de métodos de uso único. Esses tipos de arquiteturas de aplicativo dificultam o refator e a depuração e aumentam os tempos de integração para novos membros da equipe ou fornecedores. Eles também reduzem o valor dos aplicativos entregues à empresa, pois a funcionalidade não é reutilizável.

Considere o seguinte para gerenciar o estado em uma organização do Salesforce modular:

• Decida quando usar padrões stateful versus stateless. Os padrões com estado retêm informações em todo o caminho de execução, os padrões sem estado não. Em um sistema solto, padrões sem estado permitem que os componentes sejam refatorados mais rapidamente e com menos efeitos colaterais. No entanto, padrões sem estado não são adequados para todos os casos de uso. Se você estiver criando componentes para operações de dados, os padrões de estado poderão ajudar na integridade e consistência dos dados em todos os seus sistemas. Use um padrão de estado se seu componente atender a qualquer um dos seguintes critérios:
  • Conhecer o posicionamento em um caminho de execução maior é essencial para o comportamento do componente
  • O comportamento do componente precisa mudar com base nos resultados de uma ação downstream (por exemplo, ele precisa alterar a execução com base em mensagens de reversão/erro/sucesso de componentes downstream)
  • O componente precisa aguardar respostas de um sistema externo ou downstream para concluir seu trabalho
• Criar categorias significativas para informações de estado. Estado é um termo ambíguo que pode ser aplicado a um conjunto tão profundo e amplo de informações dentro (e além) de uma organização do Salesforce que por si só o termo é quase sem significado. Uma primeira etapa necessária para criar padrões de estado, portanto, é criar categorias significativas para os caminhos de execução de estado mais importantes (ou tipos de comportamentos de estado) em seu sistema. Algumas categorias a considerar:
  • Navegação e formulários
  • Operações de banco de dados
  • Operações em lote e em massa
  • Erros
• Definir estados relacionados a dados em termos de transações de banco de dados. Os comportamentos integrados da plataforma limitarão a maioria das considerações de estado para dados no Salesforce. Não tente lidar com ou contra esse comportamento. Projetar para e com isso. Projete soluções que minimizam ou eliminam a lógica de transação distribuída. (Consulte tratamento de dados para obter mais detalhes).
• Identifique estados que ocorrem dentro (e entre) unidades funcionais. Conforme você monta unidades funcionais em sistemas maiores, esteja ciente de quando estiver misturando o comportamento do componente sem estado e com estado e evite combinações que possam criar loops ou lacunas infinitas no processamento.
• Definir transferências. Considere que padrões de mensagens ou de envio os componentes usarão para transmitir dados relacionados a estado para outra parte do sistema. Certifique-se de que você está criando consciência sobre transações e tratamento em seus componentes. Não inclua nenhuma lógica de transação distribuída em suas transferências.
• Criar mapeamentos entre seus diagramas de processo e estados. Os diagramas de processo detalham as etapas que movem as informações pelo seu sistema em vários pontos no tempo. Um diagrama de estado mostra as alterações reais nas informações (o estado). Use a parte do rodapé de metadados dos Diagramas do Salesforce para capturar o estado de alteração das informações em cada etapa do processo. Se você separar diagramas de processo e diagramas de estado, lembre-se de vinculá-los. Esse conceito não deve ser confundido com capturar o estado atual e futuro dos processos ou paisagens do sistema durante o design e a implementação, pois isso não se refere às informações que passam pelo sistema.

A lista de padrões e antipadrões abaixo mostra como é o gerenciamento de estado adequado (e ruim) em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar locais em seu sistema que precisam ser refatorados.

Para aprender mais sobre ferramentas do Salesforce para gerenciar o estado, consulte Ferramentas relevantes para composível.

A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para separação de preocupações no Padrão & Anti-Padrão Explorador.

Em um sistema arquitetado para interoperabilidade, os componentes podem trocar informações e operar juntos de modo eficaz. A interoperabilidade é uma chave para tornar um sistema modular composível em vez de ser isolado. A interoperabilidade pode ser difícil de ser alcançada em um sistema coplado livremente. É necessário estabelecer padrões para métodos consistentes de integração que não minem a independência entre unidades e a separação de preocupações em geral em todo o sistema.

A interoperabilidade também afeta a qualidade das experiências do usuário. Seus usuários esperam que os dados criados em uma área (como informações do pedido) sejam utilizáveis em outra (como campanhas de marketing), e seus criadores esperam que, se aprenderem a fazer algo (como criar um fluxo ou autenticar-se em uma API), encontrem técnicas familiares que funcionem quando avançarem para o próximo problema. Não projetar para interoperabilidade resultará em arquiteturas redundantes, dados replicados, ineficiências de processo e maiores custos de desenvolvimento e suporte.

Você pode criar interoperabilidade em sistemas modulares com mensagens e compromissos, bem como com o gerenciamento de API.

Mensagens e eventos são duas maneiras de habilitar componentes em um sistema para enviar e receber informações. Em termos do conteúdo que eles podem conter, os eventos e as mensagens são semelhantes. Uma diferença crucial é o comportamento do remetente. Um componente que envia uma mensagem geralmente envia dados para um destino específico e espera algum tipo de resposta do destinatário. Por outro lado, um componente emite um evento quando algo aconteceu. Não há um destino específico nem uma expectativa de uma resposta. Essas diferenças de comportamento dão suporte a diferentes padrões de comunicação. As mensagens oferecem suporte a padrões de comunicação de estado e os eventos oferecem suporte a padrões de comunicação sem estado. (Consulte Gestão do Estado para saber mais sobre essa distinção.)

É importante alinhar as equipes em protocolos e usar casos para mensagens e compromissos. Padrões pouco claros podem resultar em uma combinação de padrões em todo o seu sistema, levando a:

• Problemas de desempenho e escalabilidade em que os padrões errados são aplicados a um caso de uso específico
• Processamento inconsistente que faz o sistema parecer instável para os usuários finais
• Tempos de solução de problemas mais longos e processos de manutenção mais complexos

Considere o seguinte ao projetar mensagens e eventos para criar estruturas mais soltas na sua organização do Salesforce:

• Identifique casos de uso assíncronos e sincronizados. O uso de eventos permite comunicações sem estado e assíncronas em um sistema. O Messaging permite padrões mais controlados, de estado e síncronos de comunicação. Ao decidir quando usar mensagens ou eventos, você precisa decidir se sua comunicação precisa ser síncrona (e potencialmente bloqueadora) em vez de assíncrona e não bloqueadora.
• Defina estruturas de dados cuidadosamente. A estrutura das informações que os componentes passam entre eles é uma parte importante de manter um sistema de fácil gerenciamento e coerência. (Consulte Gerenciamento de API para saber mais sobre isso.) Uma consideração importante ao projetar uma mensagem ou evento é a frequência com que a estrutura das informações pode precisar mudar. Depois que uma estrutura de mensagem ou evento é definida e implementada em seu sistema, pode ser difícil lidar com atualizações, especialmente se o evento ou a mensagem já estiver sendo usada para enviar informações a um sistema externo.
• Mensagens do tamanho certo. Em geral, é uma prática recomendada manter os tamanhos de mensagem pequenos. No entanto, também há um equilíbrio entre o tamanho da mensagem e o volume da mensagem. Os sistemas podem processar quantidades menores de dados mais rapidamente. O ato de processamento vem com uma quantidade adicional de sobrecarga, pois os destinatários precisam desempacotar, interpretar e determinar o que fazer com as informações que receberam. Essas etapas podem levar um tempo insignificante para serem concluídas, mas podem acumular e criar um fardo nos sistemas em escala. Evite projetos que exigem que os componentes do sistema processem muitas mensagens pequenas em sequência para concluir um trabalho. Para ajustar o tamanho certo das suas mensagens, pense em projetar para os componentes de dados downstream que precisarão processar e agir com sucesso com base nas informações que foram enviadas, sem também presumir que cada componente downstream possa solicitar ou processar várias mensagens de acompanhamento.
• Design para escalabilidade. Componentes soltos podem facilitar a escala da sua arquitetura. A eliminação de dependências entre componentes permite que as equipes trabalhem para melhorar o desempenho ou a escalabilidade de qualquer componente individual com efeitos mínimos sobre os outros. No entanto, componentes soltos também introduzem uma complexidade significativa em sua arquitetura em escala (especialmente quando se trata de gerenciar estado). Identifique processos que precisam ter lógica ou dependências mais acopladas por motivos válidos de experiência do usuário ou integridade de dados e não tente introduzir padrões assíncronos/compromissados nesses processos. Use padrões baseados em sincronização/mensagem e tratamento de erro adequado.

A lista de padrões e antipadrões abaixo mostra a aparência de mensagens e eventos adequados (e ruins) em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar locais em seu sistema que precisam ser refatorados.

Para saber mais sobre as ferramentas de mensagens e agendamento do Salesforce, consulte Ferramentas relevantes para composáveis. Para obter mais informações sobre a escolha de um padrão ou ferramenta de evento para um determinado caso de uso, consulte o Guia do arquiteto para arquitetura orientada por evento com o Salesforce.

A criação do gerenciamento adequado da interface de programação de aplicativo (API) em uma solução do Salesforce permite que componentes individuais do seu sistema sigam padrões de comunicação previsíveis. O Salesforce fornece APIs integradas e seguras para usar para comunicação com sistemas fora do Salesforce. (Para obter mais informações sobre as APIs da Salesforce Platform, consulte As noções básicas de arquitetura.)

O gerenciamento de API eficaz nas soluções do Salesforce é fundamental para criar arquiteturas verdadeiramente composíveis. Ele permite que componentes dentro de uma organização do Salesforce enviem e recebam informações com eficiência. Também permite que os criadores de soluções sigam protocolos claros para como os componentes que eles criam se comunicam com outros componentes no sistema e os ajuda a identificar implementações ruins mais cedo. Além disso, ele permite que os criadores de soluções se concentrem mais estreitamente no componente em particular que estão criando ou refatorando, o que aumenta a produtividade e a qualidade.

O Gerenciamento de API no nível corporativo é um tópico separado e é melhor feito com uma ferramenta abrangente de Gerenciamento de API. (Para obter mais informações sobre a perspectiva da MuleSoft sobre este tópico, consulte O que é Gerenciamento de API?.)

Considere o seguinte para criar funcionalidades de gerenciamento de API em suas soluções do Salesforce:

• Pense nas APIs como padrões ou contratos de comunicação previsíveis. O tipo de dados de variáveis de entrada ou saída, os nomes de variáveis, as informações que devem (ou não devem) aparecer em um determinado padrão são as chaves para um gerenciamento de API eficaz. Essas definições devem aparecer em seus padrões de design e as equipes devem poder descobrir como essas definições foram implementadas em partes específicas do seu sistema por meio de sua documentação. Uma maneira de visualizar as dificuldades de mesclar alterações de um novo desenvolvimento em um ambiente de integração é olhar para elas como evidência de onde as comunicações da API foram mal implementadas (ou talvez nenhuma definição de API).

• Não limite seu pensamento sobre APIs a código exclusivo. O que define uma API nesse contexto é a consistência das estruturas e variáveis de mensagens nessa mensagem. Desde que essa consistência seja mantida, uma API pode ser implementada em código, bem como em personalizações declarativas, como fluxos modulares iniciados automaticamente (ou acionados por evento de plataforma) ou mesmo modelos de fluxo. Baseie suas decisões sobre o que definir em código versus em fluxos não na implementação da API, mas na capacidade do pacote e na testabilidade.

• Mantenha seu ciclo de vida e controle de versão simples. Como todas as partes do desenvolvimento de aplicativo, as APIs têm um ciclo de vida: definir, criar, testar, implementar e manter (incluindo descontinuação). As APIs da Salesforce Platform lançam várias versões em um ano calendário, devido ao rápido ciclo de lançamento da plataforma. (Você pode ler mais sobre esse comportamento em Noções básicas de arquitetura do Salesforce.) Isso significa que as APIs da plataforma têm um ciclo de vida bastante complexo, pois várias versões de uma determinada API precisam ser mantidas e disponibilizadas para clientes do Salesforce. Esse nível de complexidade é adequado para casos de uso de PaaS, mas provavelmente é uma complexidade desnecessária para suas arquiteturas de soluções na plataforma (consulte: Anti-patterns de legibilidade). Concentre-se em definir um propósito claro para uma API (por exemplo, tratamento de erros) e definições de linha de base claras. Tente ter apenas uma versão de cada API.

• Faça suas APIs descobríveis, acessíveis e gerenciáveis. Documente suas APIs para que os clientes em potencial possam encontrar APIs disponíveis conectando-se facilmente a eles. As APIs precisam funcionar sem problemas como parte de uma paisagem de capacidades.

• Seja iterativo. Concentre-se em definir e implementar apenas uma API interna por vez. Dessa forma, você pode se concentrar em iterar a definição de API rapidamente, encontrar o formulário certo para sua versão com suporte uma e estabelecer práticas recomendadas com base na experiência de implementação.

A lista de padrões e antipadrões abaixo mostra como é o gerenciamento de API adequado (e ruim) em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas.

Para saber mais sobre as ferramentas disponíveis do Salesforce para ajudá-lo a criar mais interoperabilidade, consulte Ferramentas relevantes para composáveis.

A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para interoperabilidade no Pattern & Anti-Pattern Explorer.

Criar capacidade de empacotamento em uma organização do Salesforce significa que a funcionalidade na organização vem de unidades que podem ser desenvolvidas e implementadas de modo independente e confiável, como pacotes. Idealmente, essas unidades são definidas como um tipo de pacote de segunda geração (um pacote desbloqueado ou pacote gerenciado para ISVs). Nota: Como soluções bem projetadas usam esses tipos de pacote exclusivamente, os pacotes gerenciados de primeira geração não são abordados aqui.

É uma coisa definir separações de preocupações e criar unidades funcionais em uma organização do Salesforce. Outra coisa é limpar e gerenciar as dependências com clareza suficiente para fazer a versão dessas unidades com sucesso como artefatos de pacote. Para atingir esse nível de estabilidade e isolamento de metadados, é necessário um nível significativo de maturidade de DevOps (e arquitetônica). Também acelera o tempo de desenvolvimento, melhora as experiências do criador de aplicativos e proporciona previsibilidade e controle a versões e gerenciamento de versão. Nem todas as organizações poderão dar suporte à infraestrutura necessária para definir, manter e desenvolver pacotes eficazes. Porém, alcançar a capacidade de empacotamento deve ser a meta final para quase todas as organizações do Salesforce.

Você pode criar capacidade de empacotamento em suas soluções do Salesforce focando acoplamento flexível e gerenciamento de dependência.

Em um sistema com acoplamento solto, as partes individuais não estão fortemente vinculadas umas às outras. Muitas das vantagens de um sistema composível derivam do acoplamento solto. Em sistemas empacotáveis, conseguir acoplamento flexível entre pacotes (e instalação de organizações) permitirá que você tenha pacotes bem definidos e ciclos de desenvolvimento mais produtivos para equipes que trabalham com pacotes.

Na Salesforce Platform, você pode criar pacotes que estão acoplados a uma organização específica. Essa funcionalidade é útil para definir unidades funcionais e experimentar com a separação adequada de preocupações em sua organização conforme você avança na maturidade do empacotamento. No entanto, se você escolher essa abordagem, perceberá poucos dos benefícios de metadados verdadeiramente empacotáveis, incluindo desenvolvimento conduzido por origem, capacidade de usar controle de versões e estabilidade de artefatos. Em vez disso, você provavelmente continuará experimentando as desvantagens de um sistema fortemente acoplado, incluindo:

• Pontos únicos de falha causando falhas e problemas de desempenho
• Implantações lentas e imprevisíveis
• Ciclos de depuração e resolução de problemas difíceis e complexos
• Problemas de escala e desempenho

A meta final para qualquer sistema do Salesforce empacotável são pacotes soltos.

Considere o seguinte ao analisar a separação de metadados do Salesforce em pacotes eficazes:

• Quais personalizações são dados versus metadados. Quando se trata de capacidade de empacotamento, a Salesforce Platform trata dados e metadados de maneira muito diferente. É importante entender quais recursos em sua organização são metadados ou dados. Você não pode incluir dados em nenhuma unidade empacotada. Conforme você decide onde começar a abstrair a funcionalidade em uma unidade empacotada, suas equipes precisarão decidir se as personalizações armazenadas como dados devem ser excluídas do pacote totalmente ou refatoradas em uma implementação baseada em metadados.
• Como a embalagem afetará as equipes. Uma realidade logística do empacotamento do Salesforce é que grande parte do trabalho de produzir e lançar uma versão de pacote requer conhecimento das tecnologias Salesforce CLI e/ou CI/CD. Isso significa que personalizações programáticas e de baixa codificação exigirão tempo e atenção de alguém capaz de trabalhar com a tecnologia DevOps relacionada ao pacote. Dependendo de como sua equipe gerencia a entrega de recursos, a adoção do pacote pode apresentar atrasos ou bloqueadores significativos para diferentes equipes em uma organização. Você precisará identificar se as equipes conseguirão gerenciar a entrega de recursos por meio de empacotamento e criar um plano para lidar com qualquer lacuna de habilidades ou equipe. As soluções podem incluir adotar a programação combinada ou implementar trabalhos de CI/CD para ambientes de desenvolvimento.
• Como as embalagens mudarão as estratégias ambientais. Em um ciclo de vida de desenvolvimento orientado por pacote, o trabalho inicial deve ser feito em organizações teste. Esses ambientes de desenvolvimento temporários orientados por origem permitem ciclos mais rápidos e iterativos. Eles também oferecem suporte a controles de acesso de ambiente mais granulares para suas equipes de desenvolvimento e maior isolamento da produção. Quanto mais dependências seus pacotes tiverem sobre metadados desempacotados ou dados que existam apenas em um ambiente de sandbox ou produção, menor será a probabilidade de que as equipes possam, na verdade, usar organizações teste. Você pode habilitar o rastreamento de origem em sandboxes, para permitir padrões de desenvolvimento orientados por origem em ambientes de organização não teste, mas suas equipes de desenvolvimento não se beneficiarão da velocidade e da velocidade iterativa de organizações teste.
• Como as versões do pacote se relacionam às versões. Planeje com que frequência e em que estágio do controle de versão do pacote de desenvolvimento deve ocorrer. As solicitações de versão do pacote são limitadas (por organização) em 24 horas seguidas. Como prática recomendada geral, faça a versão de um pacote apenas quando estiver confiante de que nenhum conteúdo do pacote precisa ser alterado. O ideal é provisionar versões do pacote após a conclusão dos processos de garantia de qualidade. Não permita que as equipes de desenvolvimento usem o sucesso ou a falha de solicitações de criação de pacote como "testes" de quão bem elas definiram os limites do pacote. Há maneiras de fazer isso sem tentar fazer a versão de um artefato de pacote.
• O que o estado final ideal deve apoiar. A estratégia de empacotamento ideal permite versões controladas e estáveis do Salesforce que podem ser desenvolvidas e entregues rapidamente. Definir um número excessivo de pacotes em toda a sua organização pode gerar novos tipos de complexidade e gargalos para as equipes de desenvolvimento. Uma organização excessivamente modularizada também pode fazer com que as versões sejam lentas e difíceis. Comece criando e lançando algumas versões de um único pacote significativo. Derive pacotes de acompanhamento incrementalmente. Pare de apresentar pacotes quando tiver um ritmo de versão que atenda bem ao seu negócio. Pacotes de reator ao longo do tempo, se as necessidades de negócios mudarem ou se a qualidade da versão diminuir. O estado de extremidade ideal do pacote é subjetivo.

Independentemente de como você decidir definir seus pacotes, você só terá sucesso na versão de um pacote solto por meio de um gerenciamento de dependências eficaz.

A lista de padrões e antipadrões abaixo mostra a aparência correta (e ruim) do acoplamento solto para empacotamento do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas.

Para saber mais sobre ferramentas do Salesforce para ajudá-lo a criar mais capacidade de empacotamento, consulte Ferramentas relevantes para componíveis.

No contexto de uma solução do Salesforce, o gerenciamento de dependência significa identificar e estruturar os relacionamentos entre os metadados em seus pacotes e os metadados nas organizações em que esses pacotes serão instalados. O gerenciamento de dependência é uma parte importante do desenvolvimento de artefatos de pacote estáveis.

Dependências podem estar em conflito com esforços para criar unidades funcionais perfeitamente separadas, copladas livremente. Em um estado de engenharia ideal, um sistema solto não tem dependências entre unidades. No mundo real, porém, eliminar todas as dependências não é prático.

Muitas vezes, o equilíbrio entre tornar os sistemas legíveis e usar unidades funcionais fáceis de usar requer uma compensação em termos de isolamento perfeito entre as unidades em um sistema. Mais pragmatisticamente, os serviços centrais fornecidos pela funcionalidade padrão da Salesforce Platform criam dependências chave e líquidas positivas para qualquer solução do Salesforce. Muitas vantagens de escalabilidade, desempenho e segurança integrados vêm da profundidade em que são integrados à plataforma. Ao projetar soluções do Salesforce empacotáveis, é importante lembrar que as dependências de pacote não são inerentemente ruins. Uma má gestão de dependência é ruim.

O gerenciamento de dependência eficaz com o empacotamento do Salesforce significa que as equipes de desenvolvimento e manutenção podem:

• Integre a novos projetos mais rapidamente e com acesso limitado ao ambiente
• Desenvolva e teste alterações rapidamente
• Entenda como a funcionalidade complexa deve ser fornecida em compromissos menores e específicos
• Controlar ritmos de versão e reduzir janelas de falha de manutenção/lançamento do sistema
• Alterações adversas de reversão previsíveis em qualquer ambiente

As técnicas para gerenciamento de dependência com o Salesforce são bastante simples:

• Use o messaging e o Eventing para lidar com transferências simples de informações de estado ou sem estado entre componentes.
• Use tipos de metadados personalizados para fornecer informações dinâmicas de tempo de execução e dar suporte a padrões de injeção de dependência.
• Permita que os desenvolvedores do Apex usem classes abstratas ou virtuais.

No final, você precisará decidir os padrões de design que são permitidos em sua organização em desenvolvimento declarativo e programático. As considerações mais importantes (arquitetonicamente) são definir onde você deseja adicionar mais complexidade de engenharia para ter menos dependências e onde você precisa tolerar mais dependências para simplificar os fluxos de trabalho do criador de aplicativos.

Conforme você cria estratégias de gerenciamento de dependência em seus pacotes, considere os dois principais princípios de organização para unidades de pacote: horizontal e vertical.

• Limites horizontais. Em paradigmas horizontais, a funcionalidade que pode ser necessária para mais de um pacote é extraída para uma camada horizontal. As camadas horizontais então se tornam a origem da funcionalidade comum e são acessadas por meio de uma dependência declarada. Minimizar a funcionalidade redundante entre pacotes é favorável em vez de minimizar as dependências.
• Limitas verticais. Os paradigmas verticais maximizam o isolamento e o acoplamento entre partes do sistema. A funcionalidade compartilhada é limitada e trabalho semelhante pode aparecer entre unidades. As dependências são estritamente limitadas, a fim de maximizar o isolamento entre as unidades do pacote.

Observe que essa não é uma ou mais decisões. Você pode combinar paradigmas verticais e horizontais conforme necessário. Geralmente, a maneira mais rápida de começar um pacote é criar camadas horizontais de serviço. Conforme a escala e a complexidade da adoção do pacote aumentam, a abstração de mais unidades verticais ajudará a simplificar processos complexos de configuração de ambiente ou integração do desenvolvedor.

Um sistema com duas unidades funcionais (A e B), por exemplo, pode ser estruturado com dependências de pacote organizadas em paradigmas híbridos vertical, horizontal e vertical-horizontal.

Independentemente do paradigma de organização de pacote que você escolher, há alguns absolutos a serem considerados:

• Não duplique metadados entre pacotes. Os metadados necessários para mais de um pacote devem ser extraídos para um ou mais pacotes declarados como dependências.
• Use as dependências integradas dos metadados da Salesforce Platform. Para criadores de aplicativos, os serviços integrados oferecidos pela Salesforce Platform fornecem uma grande quantidade de funcionalidades que podem ser configuradas rapidamente. Muitos desses serviços têm dependências integradas que os tornam difíceis de abstrair em unidades funcionais de baixo nível. Para um determinado tipo de metadados, você precisa entender onde ele se enquadra no espectro de dependências integradas e usar esse entendimento para definição de cadeias de dependências de pacote. Não comece a adoção do pacote tentando forçar o acoplamento solto em uma funcionalidade de plataforma padrão com muitas dependências integradas. Ele aumentará a complexidade (não o valor) à medida que você alcança funcionalidades de ordem superior. É também outra maneira de cair em padrão vs. custom anti-padrões. Empacote metadados de baixo para cima (menos dependências) e itere ao longo do tempo.
• Cuidado com suas cadeias de dependência. Evite criar cadeias de dependência de pacote que exigem que os desenvolvedores dividam suas alterações em muitos pacotes diferentes a qualquer momento.
• Pense sobre o que faz sentido para o controle de origem. Há duas maneiras básicas de gerenciar seus pacotes no controle de origem. O primeiro é um único monorepo com pacotes isolados dentro de pastas. A segunda é de vários repositórios com pacotes isolados em seu próprio repositório. Há complexidades para gerenciar cada tipo de estratégia de origem a longo prazo. Em termos de integração do desenvolvedor, os limites verticais são mais eficientes em vários paradigmas de repositório. Os limites horizontais são mais compreensíveis em um monorrepo. Novamente, você pode combinar e combinar estratégias conforme sua arquitetura amadurece.

A lista de padrões e antipadrões abaixo mostra como é o gerenciamento de dependência adequado (e ruim) com pacotes do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas.

Para aprender mais sobre ferramentas do Salesforce para gerenciamento de dependência, consulte Ferramentas relevantes para componíveis.

A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para empacotamento no Padrão & Anti-Padrão Explorador.

Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa pesquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.