Apex Enterprise Patterns (fflib) : Une Analyse Critique de la Scalabilité vs Overhead

Si vous avez passé plus de quelques mois à travailler dans un environnement Salesforce à grande échelle, vous avez probablement rencontré le problème du « Big Trigger ». Vous savez de quoi je parle : un seul fichier avec deux mille lignes de code, des boucles imbriquées et suffisamment de conditions if-else pour donner le vertige même à un développeur chevronné.

En tant que Salesforce Developer/Architect, vous finissez par réaliser que « ça marche » n'est pas un standard assez élevé. Le vrai défi est : Puis-je modifier cela sans tout casser ? C'est là qu'interviennent les Apex Enterprise Patterns (fflib). Créé par Andrew Fawcett et adopté par des milliers d'équipes, ce framework est souvent considéré comme le « Gold Standard ». Mais est-ce toujours le bon choix ?

Jetons un regard profond et humain sur la réalité de l'utilisation de fflib dans le monde réel.

1. Les Piliers du Pattern

Avant de le critiquer, nous devons comprendre ce qu'il essaie réellement de faire. Le framework est basé sur la Separation of Concerns (SoC), divisant votre code en quatre couches spécifiques :

• Selector Layer : C'est là que vivent vos requêtes SOQL. Au lieu d'avoir des requêtes éparpillées dans vingt classes, vous les centralisez. Cela garantit la cohérence et facilite l'ajout de contrôles de sécurité comme WITH USER_MODE.

• Domain Layer : Cette couche gère la logique au niveau de l'enregistrement. Si le nom d'un compte ne doit pas être modifié après être devenu « Actif », cette règle appartient à cette couche. Il s'agit du comportement de l'objet lui-même.

• Service Layer : L'« Orchestrateur ». Il ne se soucie pas de la manière dont les données sont récupérées ; il connaît simplement le processus métier. C'est le point d'entrée pour vos LWCs, APIs et Flows.

• Unit of Work (UoW) : C'est le héros méconnu. Il gère vos opérations DML, garantissant qu'elles sont regroupées (batched) à la fin d'une transaction pour respecter les Governor Limits.

2. Pourquoi il gagne : Le côté prévisible

La principale raison d'utiliser fflib est la prévisibilité. Quand une équipe suit ces patterns, vous n'avez pas à « chasser » la logique. Vous savez exactement où vit une requête et où une règle métier est appliquée.

Mais le vrai « super-pouvoir » est le Unit Testing.

Les tests Salesforce standard sont lents car ils nécessitent des DML et SOQL. Avec fflib et son intégration avec Apex Mocks, vous pouvez écrire de « vrais tests unitaires ». Vous pouvez simuler (mock) entièrement la base de données. Cela signifie que votre suite de tests qui prenait 30 minutes peut n'en prendre que 2. Pour un architecte gérant un pipeline CI/CD, ce gain de temps est inestimable.

3. Analyse Critique : Les points de friction

Soyons honnêtes : si fflib est si génial, pourquoi tout le monde ne l'utilise-t-il pas ?

• Le problème du « Boilerplate » : La plainte la plus courante est la quantité énorme de code nécessaire pour faire quelque chose de simple. Pour interroger un champ d'un contact, vous avez besoin d'une classe Selector, d'une Interface et d'un appel Service. Pour les petits projets, cela ressemble à un excès (overkill).

• La courbe d'apprentissage : Enseigner à un développeur junior comment naviguer dans l'injection de dépendances (Dependency Injection) est un défi de taille. Cela demande un niveau d'abstraction qui peut être intimidant.

• Performance et mémoire : Chaque couche d'abstraction a un coût. Bien que l'overhead soit généralement négligeable pour une interaction UI standard, dans le traitement de gros volumes, l'instanciation de multiples classes peut augmenter la pression sur la Heap Size. En tant que Salesforce Developer/Architect, vous devez surveiller cela de près avec les Large Data Volumes (LDV).

4. Trouver le juste milieu

Le fflib n'est pas un choix binaire. Voici comment j'aborde cette analyse dans la pratique :

1. Ne sur-optimisez pas les petites Orgs : Si vous êtes dans un environnement simple, fflib, c'est comme utiliser une masse pour casser une noisette. Restez simple et direct.

2. Adoptez d'abord le Selector : Centraliser vos SOQL dans des Selectors est un gain immédiat pour n'importe quelle Org. C'est la première étape vers une meilleure architecture.

3. Les Interfaces sont optionnelles : Vous n'avez pas toujours besoin d'une interface pour chaque service. Si vous ne prévoyez pas de simuler ce service, économisez du code.

5. Verdict Final

Les Apex Enterprise Patterns ne concernent pas seulement le code ; ils concernent la discipline. Si vous construisez un package ISV ou travaillez dans une Org massive avec plus de 20 développeurs, le « coût » du code supplémentaire est un petit prix à payer pour éviter que l'Org ne s'effondre sous son propre poids dans deux ans.

Rappelez-vous toujours l'objectif : une logique simple, directe et propre. Si le framework rend votre logique plus difficile à comprendre, vous avez perdu la bataille. Utilisez les patterns pour servir votre architecture ; ne laissez pas l'architecture être l'esclave des patterns.