We have a very large search service (written in golang if it matters) that runs on top of ElasticSearch, receive requests, builds the correspondent query, and returns the results (with some post-processing). The service handles thousands of requests per second and should be able to serve requests quickly and efficiently.
Since the service just READS from the database (writes are being handled outside of the service, asynchronous) and builds very complex queries who varies between users, requests and AB tests being run on production, most of the code in the service is code in charge of building the query.
Currently, the ElasticSearch query is being built mixing Business logic (AB tests running in production, classification of the user, etc..). In classic OO application with relational databases I'd probably use a DAL, the receives a request and know how to parse it to SQL, and then converts the returned value to something that the BL knows how to handle.
Building such a mechanism (an abstraction of our query, an intermediate language between our domain language query to ES query language) feels like an overhead. Since all of our service is really coupled to ElasticSearch, takes into consideration lots of ES features in order to increase performance, it feels like we'll just build our own objects who are replicated ES objects, and then do the mapping.
On the other hand, we think of the possibility we'll want to replace the package querying ES, or we'll want to update ES version and it will go through breaking changes, and we'll have to change a lot of code, scattered through the whole service and not centralized.
Any advice or help would be appreciated. Thanks.