Apex Enterprise Patterns (fflib): Uma Análise Crítica sobre Escalabilidade vs. Overhead

Se você passou mais do que alguns meses trabalhando em ambientes Salesforce de larga escala, provavelmente já encontrou o problema da "Big Trigger". Você sabe do que estou falando: um único arquivo com duas mil linhas de código, loops aninhados e tantos comandos if-else que deixariam até um desenvolvedor experiente tonto.

Como um Salesforce Developer/Architect, você acaba percebendo que "funcionar" não é um padrão alto o suficiente. O verdadeiro desafio é: eu consigo alterar isso sem quebrar todo o resto? É aqui que entram os Apex Enterprise Patterns (fflib). Criado por Andrew Fawcett e adotado por milhares de times, esse framework é frequentemente tratado como o "padrão ouro". Mas será que é sempre a escolha certa?

Vamos dar uma olhada profunda e humana na realidade do uso do fflib no mundo real.

1. Os Pilares do Padrão

Antes de criticarmos, precisamos entender o que ele realmente tenta fazer. O framework é construído sobre a Separation of Concerns (SoC), dividindo seu código em quatro camadas específicas:

• Selector Layer: É onde vivem suas queries SOQL. Em vez de ter queries espalhadas por vinte classes, você as centraliza. Isso garante consistência e facilita a adição de verificações de segurança como WITH USER_MODE.

• Domain Layer: Esta camada lida com a lógica a nível de registro. Se o nome de uma Account não deve ser alterado após estar "Ativa", essa regra pertence a este lugar. É sobre o comportamento do objeto em si.

• Service Layer: O "Orquestrador". Ele não se importa com a forma como os dados são consultados ou quais são as regras do objeto; ele apenas conhece o processo de negócio. É o ponto de entrada para seus LWCs, APIs e Flows.

• Unit of Work (UoW): Este é o herói anônimo. Ele gerencia suas operações DML, garantindo que sejam agrupadas (batched) ao final de uma transação para respeitar os Governor Limits.

2. O Lado "Amigável": Por que ele vence?

A principal razão para usar o fflib é a previsibilidade. Quando um time segue esses padrões, você não precisa "caçar" a lógica. Você sabe exatamente onde uma query vive e onde uma regra de negócio é aplicada.

Mas o verdadeiro "superpoder" é o Unit Testing.

Testes padrão do Salesforce são lentos porque exigem DML e SOQL. Com o fflib e sua integração com o Apex Mocks, você pode escrever "testes unitários de verdade". Você consegue simular (mock) o banco de dados inteiramente. Isso significa que sua suíte de testes que levava 30 minutos pode levar apenas 2. Para um arquiteto gerenciando um pipeline de CI/CD, essa economia de tempo é inestimável.

3. Análise Crítica: Onde surgem os problemas?

Sendo honestos: se o fflib é tão bom, por que nem todo mundo o usa?

• O Problema do "Boilerplate": A reclamação mais comum é a quantidade enorme de código necessária para fazer algo simples. Para consultar um campo de um contato, você precisa de uma classe Selector, uma Interface e uma chamada de Service. Para projetos pequenos, isso parece um exagero (overkill).

• A Curva de Aprendizado: Ensinar a um desenvolvedor iniciante como navegar por Dependency Injection e Service Providers é uma tarefa árdua. Exige um nível de abstração que pode ser intimidante.

• Performance e Memória: Toda camada de abstração tem um custo. Embora o overhead seja geralmente insignificante para uma interação de UI comum, em processamentos de alto volume, a instanciação de múltiplas classes pode colocar pressão no Heap Size. Como um Salesforce Developer/Architect, você deve monitorar isso de perto ao lidar com Large Data Volumes (LDV).

4. Encontrando o Meio Termo

O fflib não é uma escolha de "sim ou não". Veja como abordo isso na prática:

1. Não exagere na engenharia em Orgs pequenas: Se você está em um ambiente simples, o fflib é como usar uma marreta para quebrar uma noz. Mantenha o simples e direto.

2. Adote o Selector primeiro: Centralizar seu SOQL em Selectors é um ganho imediato para qualquer Org. É a "porta de entrada" para uma arquitetura melhor.

3. Interfaces são opcionais: Você nem sempre precisa de uma Interface para cada Service. Se você não planeja simular esse serviço ou fornecer múltiplas implementações, economize no código repetitivo.

5. Veredito Final

Os Apex Enterprise Patterns não são apenas sobre código; são sobre disciplina. Se você está construindo um pacote ISV ou trabalhando em uma Org corporativa massiva com mais de 20 desenvolvedores, o "custo" do código extra é um preço pequeno a pagar para evitar que a Org colapse sob o próprio peso em dois anos.

Sempre lembre do objetivo: lógica simples, direta e limpa. Se o framework está tornando sua lógica mais difícil de entender, você perdeu a batalha. Use os padrões para servir sua arquitetura; não deixe a arquitetura ser escrava dos padrões.