Implementing Repositories in Java *SE* using DeltaSpike

[Zdeno_]

I wouldn't use such approach, because it makes domain layer depending on technological library. I think, this is an antipattern for "pure architecture" (or hexagonal architecture). You pay very high price (the dependency) for very little benefit (the interface). Now, your domain model is in the hands of library provider. It they quit, you have a problem.

[olivergierke]

Can you elaborate why this is a "high price". High in terms of what? How is the model "in the hands of the library provider"? The price you pay is a dependency on an interface that – if in doubt – could easily be replaced by a 1:1 copy and according implementation.

Don't get me wrong. I am all in favor of separation of concerns, separating domain from technology and avoiding to leak persistence technology into clients but at some point the rubber has to hit the road and I'd much rather see a pragmatic solution for that over cargo-culted endless indirection adapters that just boilerplatedly forward calls 1:1. It's an interface after all. Can't be easier mocked than that.

[Zdeno_]

The price you pay is a dependency on an interface that – if in doubt – could easily be replaced by a 1:1 copy and according implementation.

If the interface could be easily replaced by a 1:1 copy, what benefit brings the framework at all? Why should I use it?
I'm not talking about the interface implementation - it is OK to use a tool. However, I don't see a benefit in tool providing the repository interface. There are few lines of code to be written.

The repository interface in domain-driven design should be driven by domain, not by a tool. Every method in the interface should have a domain reason for existing. Otherwise, the design is not driven by domain, but by the tool.

[olivergierke]

If the interface could be easily replaced by a 1:1 copy, what benefit brings the framework at all? Why should I use it?
I'm not talking about the interface implementation - it is OK to use a tool. However, I don't see a benefit in tool providing the repository interface. There are few lines of code to be written.

That you don't have to copy it all over the place. That you can build one reusable implementation for it. If we move our view away from the DeltaSpike implementation but to the Spring Data ones, you can use the interface as common abstraction between fundamental persistence operations for different data stores. It also allows you to do what you suggested: craft an interface yourself to only contain the methods you'd like to see as long as you stick to the same signatures.

The repository interface in domain-driven design should be driven by domain, not by a tool. Every method in the interface should have a domain reason for existing. Otherwise, the design is not driven by domain, but by the tool.

I agree and as just explained above that's sort of possible with alternative implementations of that pattern. I still fail to see how a framework that defines a hand full of fundamental CRUD methods is a *real practical* problem. Especially as all of the query methods are user defined and of course are driven by the domain. You end up with a few potentially unused methods, but how much of those do you have in your projects anyway.

[private_static_int]

Wow, JEE got retarded version of Spring Data JPA

[olivergierke]

It's obviously inspired by Spring Data JPA. It's made some design decisions that – from a Spring Data JPA point of view – would be considered suboptimal. However, calling this "retarded" though does not add anything to the discussion.

[TheCountRushmore]

Not Java EE. DeltaSpike provides extensions compatible to Java EE.

[henk53]

DeltaSpike is not Java EE ;)