Suggerimenti necessari su un'architettura per più client e un'applicazione web personalizzabile

Parametrizza il più possibile, naturalmente.

Evita di scrivere:

if(customer == 'foo') {
  doBarCalculation();
}

, ma scrivi:

if(customer.usesBarCalculation) {
  doBarCalculation();
}

Utilizza il modello di strategia:

customer.getCalculation().doCalculation();

Customer {
  CalculationStrategy getCalculation();
}

CalculationStrategy {
  doCalculation();
}

; puoi usare la strategia a diverse scale; o offrono molte piccole, semplici interfacce o alcune grandi interfacce: vale la pena di pensare bene alla scala; le grandi interfacce tendono a provocare la duplicazione del codice tra le implementazioni (e la duplicazione del codice è errata), mentre le interfacce più piccole sono spesso più difficili da progettare in anticipo o aumentare la complessità.

Crea una tabella di società nel database. Ogni utente viene associato a un'azienda. Ecco alcuni pseudo-SQL per le personalizzazioni aziendali per la visualizzazione di date, fuso orario, scostamento fiscale e persona di contatto:

table user:
id
company_id
... other fields ...
foreign key (company_id)

table company:
id
date_format
time_zone
fiscal_offset
contact_person
... other customization fields ...

Probabilmente hai bisogno di interrogare l'utente e la società per la maggior parte degli schermi per testare le personalizzazioni. Tirare un singolo record dal database per uno schermo non dovrebbe richiedere più di 5 ms.

Capisco che non vuoi introdurre complessità, ma avere un codice specifico dell'azienda per ogni cliente disseminato nella tua applicazione è già complesso. Meglio inserirla ufficialmente nel proprio modello di database, piuttosto che svegliarsi un giorno con 100 personalizzazioni di società una tantum disseminate nel codice. Almeno questo li mette tutti in un posto, e guardando queste impostazioni sulla schermata di modifica della società, i tester possono vedere facilmente a cosa devono pensare quando effettuano i test per diverse aziende.

La tecnica descritta è una buona soluzione per fermare la gabbia ma non si adatta bene. Va bene se hai solo pochi casi.

Mi piacciono entrambe le soluzioni di Alex e GlenPeterson sopra

1. Parametrizzazione: rende i diversi casi generalizzati e riutilizzabili. eq .: consente la spedizione internazionale (S / N) o rompere le tasse di spedizione (S / N).

2. Attributi flag del database - per registrare le preferenze di ogni cliente

Oltre a queste tecniche altre cose da considerare:

3. Codebase separati. Isolare le funzionalità di base in un'unica base di codice. Personalizzazione del cliente in una base di codice diversa che utilizza la base del codice principale. Questo può essere difficile da configurare, ma consente di sviluppare liberamente entrambe le codebase in modo indipendente. Avere buoni test sulla base del codice core aiuterà a evitare di rompere le basi di codice personalizzate.

4. Separa i database (uno per ogni client) o Namespace le tue tabelle di database (una tabella per ogni client)

5. Utilizza file di configurazione separati per ciascun cliente. Yaml è ottimo per i file di configurazione. Questo può essere molto più leggero di mettere tutti i flag nel database e ti permette di modificarlo facilmente.