Logica aziendale contenuta all'interno di JSON

Fondamentalmente una politica come quella è solo dati. La logica di business di un'applicazione come quella di HSBC è più attenta all'esecuzione delle regole codificate dalla policy come la convalida dei vincoli, l'esecuzione di attività pianificate, ecc. Di quanto non sia con i dettagli di una particolare politica.

Quando la serie di politiche cambia molto raramente, ha senso scriverle nel codice, che può essere eseguito in modo efficiente con strumenti regolari. Tuttavia, se le politiche devono essere aggiunte o sovrascritte, modificate settimanalmente o altrimenti altamente mutabili, codificare la politica in un formato non di codice aggiunge la flessibilità necessaria non attivando una ricostruzione su ogni modifica di criterio. Diventa quindi la migliore pratica per spostare le informazioni sulla politica in un'unica fonte all'ingrosso. Anche se è improbabile che un campo dati in una politica cambi, ci vorrebbe un motivo molto convincente per separarlo.

Inoltre, quando una politica viene rappresentata come dati, può essere condivisa con sistemi compatibili come nel caso qui con l'API della carta di credito di HSBC. La documentazione che hai postato afferma (sottolineatura mia):

This API will return data about all commercial credit cards products and is prepared to the Open Banking standards as defined by the Open Banking Implementation Entity (OBIE) in data dictionary version 2.1. It is regulated by the UK Competition and Markets Authority (CMA). Data is only available for the United Kingdom.

Quindi non ha senso fornire la "logica aziendale" (cioè le informazioni sulle politiche) nei risultati di questa API da un punto di vista tecnico, potrebbe anche essere richiesto dalla legge .

Dato questo background, ciò che significa per la tua applicazione è che deve essere solido per le modifiche nelle politiche segnalate da HSBC. Ciò che questo effettivamente comporta, sospetto, è codificato dall'OBIE, come indicato nella documentazione. Ma qualunque cosa tu faccia effettivamente, il fatto che HSBC debba codificare le loro politiche come dati significa che lo fai anche tu, dato che potrebbero cambiare in qualsiasi momento. Sarebbe molto fragile aggiornare personalmente una classe in risposta a cambiamenti esterni come li noti.

Dati è Codice

Quindi, quando HSBC distribuisce le informazioni sul prodotto tramite JSON, passano essenzialmente il codice. Per utilizzarlo nella propria applicazione è necessario implementare un motore che interpreti quel codice e applichi gli effetti. Questo può essere fatto in diversi modi.

Hai già evidenziato Compilando questo codice scrivendolo manualmente nelle tue classi. In questo senso tu, lo sviluppatore, sei l'interprete. Essendo un essere umano nel ciclo, è naturalmente più lento da aggiornare e, essendo pre-compilato, è più veloce da eseguire.

L'altro modo per farlo è scrivere un interprete . In questo caso l'applicazione interpreterà direttamente il codice ricevuto. Funzionerà un po 'più lentamente in quanto i controlli extra devono essere eseguiti prima per garantire che il codice ricevuto sia valido, ma è molto più flessibile consentendo di implementare nuove versioni di quel codice sulla piattaforma senza dover ridistribuire la piattaforma stessa.

Esiste un compromesso tra costi e benefici e nessuno dei due è migliore . Dipende dal tasso di cambiamento atteso. Di solito applico il principio della forza di taglio a questo tipo di problema.

Forza di taglio

Il codice che cambia spesso dovrebbe essere separato dal codice che cambia raramente.

Il fatto che l'applicazione abbia un controllo dell'età non cambierà probabilmente, l'età minima per la verifica è suscettibile di cambiare semplicemente essendo in un altro paese.

Ora considera il tuo codice per isolare il codice che cambia più velocemente, dal codice che cambia più lentamente. Spingi il codice che cambia più velocemente in argomenti di funzione o argomenti del costruttore (per oggetti). Continua a spingere finché il codice che cambia più velocemente trova altro codice che cambia allo stesso ritmo.

È perfettamente legittimo inserire questo codice in un file di configurazione, in un database o anche in un servizio di rete remoto. Basta non dimenticare di implementare una buona sicurezza. Permettere il codice da eseguire da una fonte non affidabile è una ricetta per il disastro.

... however this is more challenging because it is necessary to recompile and deploy. Therefore I am wandering if the business logic should be contained in the database ...

Hai un punto, ma copre solo parte della logica.

Sì, l'età è solo un numero e quindi dati. Se l'età cambia da 18 a 21, può essere gestita con un semplice cambiamento di configurazione. Ma quanto sei sicuro che quell'età sia solo un numero?
Ad esempio, se l'età minima cambia per alcuni degli utenti (ad esempio in base alla loro nazionalità o genere), non è più così semplice. Dovresti quindi avere impostazioni di configurazione per ogni combinazione di nazionalità / genere, che può portare a un sacco di gonfiore nei tuoi file di configurazione. Ogni volta che viene aggiunta una nazionalità (che probabilmente accadrà a runtime senza bisogno di una ridistribuzione), sarà necessario aggiungere anche le nuove impostazioni di configurazione della nazionalità.

Il fatto è che le modifiche alle regole di convalida non sono sempre così semplici come la modifica di un valore. Quando alcuni dei comportamenti cambiano, sarai sempre bloccato a dover ridistribuire la tua applicazione. Anche se assicuri che tutti i valori siano facilmente configurabili, copre solo un sottoinsieme di possibili modifiche che possono essere apportate alla logica aziendale.
La domanda diventa quindi se il vantaggio di essere in grado di scambiare i valori (ma non la logica) contribuisca significativamente all'applicazione. Se la modifica di qualsiasi alle regole di convalida deve essere considerata una modifica con un impatto maggiore, non c'è motivo di garantire che le modifiche ai valori siano notevolmente più semplici delle modifiche logiche.

In secondo luogo, avere le impostazioni nella compilazione significa che hai una qualche forma di garanzia di coerenza. Se si compila l'età minima nella DLL, allora si sa che la stessa versione dell'applicazione non modificherà mai il suo comportamento. Soprattutto per sistemi di grande importanza come il banking, può essere desiderabile aggiungere uno strato di immutabilità comportamentale.

Indipendentemente dalle convalide aziendali, avrai sempre un ambiente di produzione sicuro perché vuoi impedire alle persone di scambiare impunemente le DLL (sia che si tratti di intenti malevoli o di manutenzione imprudente). Se hai comunque quella sicurezza, avere le regole di convalida compilate nella tua DLL significa che hai lo stesso ambiente sicuro per garantire che nessuno cambi le regole di convalida (che si tratti di intento malevolo o errore umano).

Alla fine, se si mettono le regole di convalida nel database, nel file di configurazione o nei cardini di assemblaggio su una domanda: Vuoi poter cambiare le regole di convalida senza ridistribuire l'applicazione?

Non esiste una risposta obiettivamente superiore a questa domanda. Diverse aziende hanno priorità diverse e diversi tipi di convalida possono avere impatti diversi sul business quando qualcosa va storto.