How to abstract the data layer when using Spring Data?

Question

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.

Answer 1

You should forget your misguided goal. The data abstraction you so eagerly wish to reimplement is already provided by Spring Data's repositories. You can't really create "framework agnostic business logic"(1). It would be like writing "programming language agnostic code".

If you were to use something like BPEL you could achieve separation, but that's a different beast altogether.

Your code will be dependent on Spring, because you're using Spring. That's not a bad dependency that should be avoided. If you decided to ditch Spring and use something else instead, you would be doing a full rewrite anyways. Any custom abstractions would've been wasted development time.

Note that in proper architecture you get good abstractions from the layers higher than the repository (service, facade). I'm assuming you're talking about a custom layer between service and repository, which is useless.

Edit: If I were in your hypothetical situation of switching to OrientDB, switch to using OrientRepository, and the switch would be pretty seamless.

You were talking about "framework agnostic", but you seem to concentrate on "persistence agnostic" which is what Spring Data aims to provide. It doesn't provide "all persistence agnostic", because while it's easy to create an abstraction layer like JDBC (although even with that you might want to dig into the implementation classes for database specific functionality), widening the abstraction also means more restrictions as the abstraction can only provide the functionality that all the implementations have. Just like how CrudRepository provides very basic operations and its subinterface JpaRepository provides additional JPA specific operations.

In the real world even switching the database to a different one is usually quite uncommon and would require a lot of work and preparation, even though there are good standards and abstractions. Switching to a completely different persistence mechanism would be an even bigger task, something that an additional abstraction layer would not be able to mitigate in any real way.

In your case, you'll be writing something basic like dao.save(entity) anyway, and the repositories already abstract that quite nicely. You might not get a complete drop-in replacement, but that's not how things work in real development anyway. I'd avoid over abstracting things to account for imaginary future requirements. That just results in overengineering and your actual goal (the board game) is left behind.

Answer 2

Actually your goal is fine so long as you understand what it will get you and what it will cost.

But you're going about it the wrong way. You want your business layer to be independent of your persistence layer? Fine. Then stop thinking about Spring. Stop thinking about persistence.

Make your game work without any persistence at all. Work out what your business rules are. What your model needs to be. Sure state dies when you turn off the computer but you can still get pretty far this way.

Now that you know what your game is what do you want saved? What API should you offer so that state can be saved and rebuilt. Done this way you focus on your real needs and not on what some framework offers out of the box.

You may have to do more work. You may miss out on some Spring features. If you want this to work you have to be ok with that.

But now, if you ever want to, you can swap out Spring for something else. You could even create your own persistence code.

I know this works because I've done it. It's not cheap. But it works. Sometimes it's even worth it.

What does this get you?

You create a place in the code that doesn't know about Spring and doesn't know about persistence then changes to those things won't impact that place. In that place you put your business rules. No one should be able to look at the code for this place and tell that you're using Spring or Mongo DB. Do that faithfully and you won't be coupled to either one. At least not here. Do this and your business rules will be protected from change that has nothing to do with your business rules. As a bonus, people that haven't studied Spring or Mongo DB will still understand the code here.

What does this cost?

By deliberately avoiding making choices to make things easier to use Spring or Mongo DB you end up having to create a translation layer between your pristine business logic and code that bows to the needs of Spring and Mongo DB. This translation layer is what will be impacted by changes to Spring and Mongo DB. Creating that layer is work. It comes at a cost. It robs you of some of the tempting benefits of these tools. If you're fine being as tied to these tools as you are to your programming language then that work has been wasted.

No autowiring?

If you're surprised that I have kicked not only Mongo DB but Spring as well out of your business rules since Spring isn't just about persistence then let me be clear: construction logic doesn't belong in your business rules any more that persistence logic does. Spring can help without your beans knowing it exists.

There are ways to make use of all of these tools without letting them seep into every part of your code base. But fighting the tools desire to be everywhere is work. You don't get isolation for free.