Un'unica fonte di verità all'interno di un sistema distribuito aziendale

L'approccio più architettonicamente valido che conosco è quello di mettere quell'unica fonte di verità dietro un microservizio. È perfettamente accettabile che più parti del sistema aggiornino tali dati, a condizione che lo facciano attraverso qualcosa come un microservizio che può garantire che sia sempre fatto correttamente e in modo prevedibile.

Quindi, ad esempio, i dati dei clienti sono probabilmente già in un database, ma tutte le letture e le scritture dei dati del cliente dovrebbero passare attraverso un singolo servizio il cui unico scopo è quello di fornire un'interfaccia limitata per manipolare i dati dei clienti. Questo fornisce un luogo comune per cose come la logica di validazione e l'ottimizzazione delle query, e assicura che le modifiche ai dati avvengano sempre in modi molto specifici a cui hai pensato in anticipo e sono sicuro che andranno bene. Ad esempio, puoi fornire una richiesta deleteCustomer che garantisce che tutti i dati della carta di credito per quel cliente vengano eliminati anche quando il cliente lo fa. Questo rende anche molto più facile cambiare le tabelle del database sottostante in futuro.

Trovare il microservizio corretto non dovrebbe essere più difficile che trovare le tabelle del database corrette e l'API del microservizio dovrebbe essere significativamente più facile da usare correttamente di uno schema di database. Inoltre, dovrebbe essere un involucro molto sottile; la maggior parte di quelli che uso e scrivo al lavoro mappano semplicemente ogni richiesta a una singola istruzione SQL. Logiche più interessanti come l'utilizzo dei dettagli della carta di credito per caricare qualcuno o la consegna del proprio articolo appartengono altrove.