I have decided to try to create my own board game implementation. Probably going to use a REST-api to expose the contract. I'll figure out what database, communication, ... tools I'm going to use once I've got my business logic set.
Now, to achieve not being dependent on tools/frameworks in my business layer, I need to abstract the, for example, persistence layer. This is where my dilemma comes in to play. I will probably use Spring Boot but I want it to stay away from my business logic.
To achieve this; should I wrap the typical CrudRepository interfaces which Spring Data provides in an adapter of my own to ensure that my business logic doesn't know anything about Spring? I have never seen anybody doing it in a professional setting(although I'm a beginner so it might be common practice). Or are there other means to achieve my noble goal of the business logic being framework agnostic?
Thanks in advance!
Per request, a purely hypothetical situation:
Let's say my business logic has been coded and it's time to decide on the database. I go for a MongoDB. Natively supported by Spring, and falls under the same abstraction as, for example, the Spring support for relational databases. However, let's say that after a year, I decide to switch to another database. I choose OrientDB, which is not natively supported by Spring. But I am coupled to the Spring data abstraction in my business logic, so I have to change my business logic to switch databases.
If I had an extra layer, which maps the logic of my business domain, to operations on my database, I could just plug-in another implementation.
Specifically, if I need to create an order in my business logic, I could call repository.createOrder(...) in my service without knowing which specific database is behind that repository or which library/framework performs the mapping. All that is taken care of in that extra layer.