Abbiamo un servizio di ricerca molto ampio (scritto in golang se è importante) che funziona su ElasticSearch, riceve richieste, costruisce la query corrispondente e restituisce i risultati (con qualche post-elaborazione). Il servizio gestisce migliaia di richieste al secondo e dovrebbe essere in grado di servire le richieste in modo rapido ed efficiente.
Poiché il servizio si limita a leggere dal database (le scritture vengono gestite all'esterno del servizio, asincrono) e crea query molto complesse che variano tra utenti, richieste e test AB eseguiti in produzione, la maggior parte del codice nel servizio è codice responsabile della creazione della query.
Attualmente, la query ElasticSearch viene costruita combinando la logica aziendale (test AB in esecuzione in produzione, classificazione dell'utente, ecc.). Nella classica applicazione OO con database relazionali probabilmente utilizzerei un DAL, la riceve una richiesta e sa come analizzarla su SQL, quindi converte il valore restituito in qualcosa che il BL sa come gestire.
Costruire un tale meccanismo (un'astrazione della nostra query, una lingua intermedia tra la nostra query sulla lingua del dominio e il linguaggio di query ES) sembra un sovraccarico. Poiché tutto il nostro servizio è realmente accoppiato a ElasticSearch, prende in considerazione molte funzionalità ES al fine di aumentare le prestazioni, sembra che semplicemente costruiremo i nostri oggetti che sono oggetti ES replicati e quindi faremo il mapping.
D'altra parte, pensiamo alla possibilità di voler sostituire il pacchetto con l'interrogazione di ES, o vorremmo aggiornare la versione di ES e passerà attraverso cambiamenti bruschi, e dovremo cambiare molto di codice, sparsi per l'intero servizio e non centralizzati.
Qualunque consiglio o aiuto sarebbe apprezzato. Grazie.