Struttura del codice per gestire più mercati? (regole aziendali diverse per ogni stato negli Stati Uniti)

Avere un'unica app e progettare la soluzione di configurazione appropriata.

JacquesB suggerisce questo, ma voglio affermarlo con più forza. Tu devi fare questo per configurazione invece di sviluppare più di 50 versioni di codebase. Qualsiasi altra cosa sarà irragionevolmente ingestibile.

Se esistono requisiti complessi che non possono essere gestiti da semplici parametri di configurazione, progettare una soluzione di configurazione più complessa.

La tua configurazione potrebbe anche avere un semplice linguaggio di scripting che definisce i requisiti logici. Va bene. La chiave è che la "configurazione" deve essere separata in modo pulito dalla base di codice dell'app.

Altrimenti, cose come identificare e correggere bug saranno un disastro. Con il normale controllo delle versioni oltre alle versioni specifiche della locale, avrai centinaia di versioni sul campo. E non sarai in grado di dire facilmente se un bug è correlato al codice specifico locale o al codice base.

Inizia a pensare ai casi limite adesso

Questa è una situazione in cui c'è un alto rischio di fare ipotesi errate che saranno incredibilmente costose. Ad esempio: "Ogni utente di app avrà sempre e solo bisogno di operare all'interno di un locale". È vero? Assicurati di pensare seriamente a tali problemi il prima possibile.

Dipende molto da che è diverso. Si tratta di qualcosa che può essere espresso esclusivamente per configurazione (ad esempio, aliquote fiscali) oppure è necessaria una logica di codice separata per ogni stato? Quanto più puoi gestire semplicemente per configurazione, meglio è!

molto probabilmente non richiede codice separato per stato. Ad esempio, menzioni che alcuni mercati emettono rimborsi mentre altri rimpiazzi di problemi. Questo è ancora solo due percorsi di codice che devi testare. Quindi puoi avere una configurazione che indica quale percorso deve essere usato per quale stato. Questo è molto migliore di avere un codice separato per ogni stato. Devi solo testare due percorsi di codice più vecchi di 50.

Se hai mai sentito il bisogno di scrivere codice individuale per ciascuno dei 50 stati, probabilmente stai sbagliando. Non dovresti assolutamente avere progetti separati per stato, o anche avere "50 diversi" di qualsiasi cosa tranne le sezioni delle configurazioni.

Ho avuto alcune esperienze pratiche con tali progetti e posso almeno offrire alcune linee guida generali.

• JacquesB ha assolutamente ragione che la configurazione è il tuo migliore amico. Sia che tu metta quella configurazione nei file o nelle tabelle del database sia una scelta stilistica (anche se mi piacerebbe essere inclinata verso i file di configurazione, dato che una volta che hai impostato un servizio, sono disposto a scommettere che non cambierà molto). / p>

• Aspettati un codice molto più indiretto di quello a cui probabilmente sei abituato. Ci saranno molti posti in cui invece di dire "Fai questo il prossimo", dirai "Chiedilo al config per quello che dovremmo fare dopo, poi vai a farlo". Che può essere un mal di testa per lo sviluppo, ma ti ci abituerai.

• Suggerirei una struttura di "Questi sono gli elementi comuni che tutti probabilmente vogliono, e questi sono gli elementi su misura progettati a mano per i singoli stati". A tal fine, l'identificazione corretta di tale funzionalità predefinita sarà una parte importante di quanto sia facile / terribile il codice con cui lavorare in futuro. Preparati a fare qualche refactoring quando impari che più cose di quanto pensavi debbano essere configurabili.

• Assicurati sempre che tutti i messaggi di errore provenienti dagli elementi personalizzati identifichino esattamente da dove provengono. L'enorme numero di diversi percorsi di esecuzione significa che il debugging farà schifo a prescindere da cosa; tutto ciò che puoi fare per ridurre la quantità di caccia alle uova di Pasqua sarà più che utile.

• Risparmia tempo per creare una buona suite di test automatizzata. Una suite di test automatizzata DAVVERO buona. Questa è sempre una buona pratica, ma per te potrebbe letteralmente significare la differenza tra successo e fallimento. Di nuovo, è l'enorme varietà di percorsi di esecuzione; eventuali modifiche al codice comune ti lasceranno vulnerabile agli insetti con effetto farfalla nei rami che non ti aspettavi. Devi catturare questi bug prima che colpiscano la produzione.

Sebbene la configurazione possa aiutare a non risolvere tutti i tuoi problemi, potrebbe crearne di nuovi.

Il modo migliore in assoluto nella mia esperienza è di creare una soluzione multi-tenancy in grado di gestire tutti o nessuno degli stati (inquilini)

Ciò richiederà la configurazione. cioè percentuale di imposta sulle vendite per stato, ma anche codice condizionale LegalMethodOfCalculatingWorkingHoursA vs B

Se la tua app è ospitata / online potresti prendere l'approccio microservizi al codice condizionale ma una soluzione off line dovrà raggruppare tutti i moduli opzionali e selezionarli tra loro

Troverai alcuni moduli riutilizzati in tutti gli stati, come la tassa sulle vendite e alcune leggi pazze utilizzate solo in un singolo stato. Scoprirai anche che le leggi cambiano nel tempo. quindi i moduli utilizzati variano di volta in volta in un singolo stato

Quindi sceglierei la denominazione in base alla funzionalità anziché a quella dello stato.