Avere filiali nel codice che sono abilitate per cliente non è una soluzione pratica. 20 clienti con richieste speciali più avanti e il tuo codebase è una pila di escrementi.
Quindi ti suggerirò di utilizzare i flag di funzionalità. Un flag di funzionalità è una sorta di proprietà di configurazione booleana. Questi flag dovrebbero idealmente essere memorizzati in un luogo che non richiede che uno sviluppatore li modifichi (ad esempio configurazione funzionale, al contrario della configurazione tecnica).
Utilizza uno per ciascuno dei campi facoltativi:
- nome
- età
- Departement
- esperienza
(detto qualcosa come employeeNamesEnabled )
Nell'unico ambiente, attiva il nome e il flag di età. Dall'altro, le bandiere del dipartimento e dell'esperienza. Tutto il codice che deve gestire queste esigenze deve essere ramificato sulle bandiere.
Inoltre, sembra che la tua squadra / azienda non sia a conoscenza del pieno effetto che questo avrà. Pensa a quali conseguenze hanno questi campi aggiuntivi per altre logiche di business. Definisci il comportamento desiderato dell'applicazione per diverse configurazioni di flag nelle aree che toccano questi campi prima di eseguire qualsiasi codifica.
Inoltre, è necessario riflettere seriamente su quali richieste speciali si desidera supportare solo per alcuni clienti. Con questo approccio, anche se hai 20 "versioni" della tua applicazione per 20 clienti diversi che lavorano con il codebase sarà un incubo al meglio.
Un'altra alternativa è consentire ai tuoi clienti / inquilini di definire campi arbitrari per ogni entità. La tua applicazione dovrebbe solo validare e archiviare quelle ma non elaborarle su di esse. Pro: i clienti possono aiutare se stessi, non è necessaria nemmeno una telefonata alla tua azienda. Con: nessuna logica di business su campi personalizzati.