All the service layer needs to know is: “at runtime, some form of repository is provided to me”. Alternatively, you can use an Abstract Factory to retrieve a repository instance. Personally, I prefer IoC.

Hope this answers your question.

thanks for your comment.

placing the interfaces in a separate JAR gives you almost all of the benefits I described in my post. However, that will likely create a jar file creating only very few classes that are, in my opinion, conceptually tightly coupled to the domain. That’s why personally, I would prefer to place it in the jar where the domain is implemented.

Regarding Your comment:

However, replacing the persistence layer with another one isn’t as easy as it seems when it contains the interface. To be able to do so, you must copy the interface into the new persistence layer implementation. And as any good developers knows, when you’re copying stuff, take your hands off the keyboard, and think for a second. You’re probably doing something wrong.

After few projects on my own in Java and using Maven, I’ve decided to separate Interface of Repository and it’s implementation. So I actually have two different JAR’s that is specified as dependency in Application Layer. As You can see there is no need to copy interface in domain layer, interface of repository can be left as it is , and when You need another implementation of repository You just write new Interfaces implementation.

I can be more descriptive about this if You wish.

It makes sense, when you think about it. Perhaps the reason that most developers do it differently is that the difference between “Domain” and “Core domain” (to use Eric Evans’ terminology) is hard to spot at first.

Nice one as usual, Allard.

that’s a very good and valid point you make there. I would lie if switching persistence implementation was a fully transparent and non-intrusive job. Fortunately, I would say, as simple transitions would make our job boring.

However, all persistence frameworks (ORM or other) provide the same simple set of features: store, fetch and find. How these features are used using a specific ORM tool should be hidden inside the implementation of the persistence layer. Details such as open-session-in-view (which I dislike, but that’s another discussion), caching and transactionality are usually quite nicely abstracted away by frameworks like Spring. But, I have to admit, they aleays leak through at least a little bit.

Recently, I had to replace a JCR (Java Content Repository) with an ORM solution. Unfortunately, the persistence layer was not as nicely decoupled as it could have been (with relatively little investment at the time). The investment seemed big and useless at the time, but would have been well worth the trouble.

Full decoupling is quite hard to achieve and would often require advanced use of things like AOP. Personally, I prefer the pragmatic solutions. If there is a quick win (like keeping the repository interface technology agnostic), I take it. If there are any leaks, make them visible and easy to replace.

Finally, about “query by specification”, there is a very nice topic about that in Evan’s book. If you use the Abstract Factory pattern to create specification objects, it’s easy to create a basic interface that allows you to specify most commons forms of specification (equals, and, or, etc…), regardless of the actual implementation chosen.

I hope this helps.

Specific to DDD, implementing patterns like query-by-specification are wildly different (sometime non-portable) across persistence technologies.

Any details on how you managed to pull this off?