J'ai maintenant quelques gros produits multi-locataires basés sur le Web, et très bientôt je peux voir qu'il y aura beaucoup de personnalisations spécifiques au locataire.
Un champ supplémentaire ici ou là, peut-être une page supplémentaire ou une logique supplémentaire au milieu d'un workflow - ce genre de chose.
Certaines de ces personnalisations peuvent être intégrées au produit principal, et c'est formidable. Certains d'entre eux sont très spécifiques et gêneraient tout le monde.
J'ai quelques idées en tête pour gérer cela, mais aucune ne semble bien évoluer. La solution évidente est d'introduire une tonne de paramètres au niveau du client, permettant d'activer diverses «fonctionnalités» par client. L'inconvénient de cela, bien sûr, est la complexité et l'encombrement massifs. Vous pouvez introduire un nombre vraiment énorme de paramètres et, au fil du temps, divers types de logique (présentation, entreprise) peuvent devenir incontrôlables. Ensuite, il y a le problème des champs spécifiques au client, qui demande quelque chose de plus propre que d'ajouter simplement un tas de champs nullables aux tables existantes.
Alors, que font les gens pour gérer cela? Force.com semble être le maître de l'extensibilité; évidemment, ils ont créé une plate-forme à partir de zéro qui est super extensible. Vous pouvez ajouter à presque tout avec leur interface utilisateur Web. FogBugz a fait quelque chose de similaire en créant un modèle de plugin robuste qui, à bien y penser, aurait pu être inspiré par Force. Je sais qu'ils y ont consacré beaucoup de temps et d'argent et si je ne me trompe pas, l'intention était de l'utiliser réellement en interne pour le développement futur de produits.
Cela ressemble au genre de chose que je pourrais être tenté de construire, mais probablement pas. :)
Un investissement massif dans une architecture enfichable est-il la seule solution? Comment gérez-vous ces problèmes et quel type de résultats voyez-vous?
EDIT: Il semble que FogBugz ait géré le problème en construisant une plate-forme assez robuste, puis en l'utilisant pour assembler leurs écrans. Pour l'étendre, vous créez une DLL contenant des classes qui implémentent des interfaces comme ISearchScreenGridColumn, et qui devient un module. Je suis sûr que la construction a été extrêmement coûteuse compte tenu du fait qu'ils ont un grand nombre de développeurs et qu'ils y ont travaillé pendant des mois, et que leur surface est peut-être 5% de la taille de mon application.
En ce moment, je me demande sérieusement si Force.com est la bonne façon de gérer cela. Et je suis un noyau dur ASP.Net, donc c'est une position étrange pour me retrouver.