从域类抽象数据库ID的策略

Question

I am writing a simple CRUD application in Java and Spring4 with spring-data, and I want to see if I can keep the domain as pure/clean as possible, and I'm after some ideas/thoughts as to how I can go about achieving this.
I've structured the project with a parent pom and some child modules as follows:

parent pom
    |- domain
    |
    |- persistence
    |   |- api
    |   |- impl
    |
    |- service
    |   |- api
    |   |- impl
    |
    |- rest

In the persistence api module I have interfaces with methods for persisting/retrieving my domain classes. eg:

public interface GiftPersistence() {

    Gift saveOrUpdateGift(Gift gift);
    /* other methods ... */
}

Importantly, these methods are not repository methods. The methods in this module are those that are called by the service module implementations.

The persistence impl module has an implementation of the interface that is specific to the database that I'm using (it's mongo today, but could be oracle or ms-sql, or anything else). This is where I have my repository interface that is specific to the database vendor.

In the domain module I have my domain classes, but I don't want to model in anything that is database centric. eg:

public final class Gift {

    private String description;

    private boolean claimed;

    private String claimedBy;

    /* getters & setters etc ... */
}

The reasons I don't want to model database specific things are:

• Persistence is not a concern of the domain
• Different database vendors might use different id strategies/datatypes, and I don't want to couple my domain code to any database vendor
• I might want to import the domain module into another project's pom, and that project might not do anything with a database

I've been involved in a project in the past that did something similar (to be honest, that's where I've got the idea from!), but I don't have access to that project any more so can't use it to crib ideas.
Having said that I vaguely remember it did something with jackson mixins (though that might have been a similar idea/concept, but closer to the web concern than the db concern).
The other approach I've thought about is using aspects, but not really sure how/where I'd go about that.

So, any ideas or thoughts as to how I might achieve the goal of keeping my domain clean of database concerns would be very much appreciated.

Edited with new idea I just found
This is an interesting idea - https://github.com/CK35/example-ddd-with-spring-data-jpa
The idea is that the domain module models the domain classes as interfaces, and the concrete implementations are (in my case) in the persistence-impl module. This way they can be annotated with domain concerns, including additional properties such as id.
This feels like a nice option as it means the domain is clean (albeit not a concrete implementation), and we can have different implementations of the persistence-api module, where the implementations of the domain classes have generic jpa annotations, or mongo annotations, or oracle ...

Any other ideas?

Answer 1

If you want you can use an interface, although you'll probably find that you only ever have one implementation of this interface, defeating the whole purpose of the interface. Annotations themselves are pretty much interfaces. So an annotated class will be much the same.

I'm not sure why you think having an ID field will mean that the class will be database dependent. The whole design intent of spring is to not make it interface with any persistence technology you want, and so you can use hibernate or whatever for persistence. If you do use hibernate you could configure your persistence classes in xml, so you won't see any persistence stuff in your domain object... except the ID of course, though I don't see this as a problem, if it is a massive problem well you could extend from a base class which has a private id field but you might not like that.

When you do annotate a domain object with persistence concerns, won't have any problems with other client code which doesn't want to know about persistence. They will only be able to see it if they are using reflection or something crazy to read annotations.

IMHO making all services, daos, entites, and all this stuff into interfaces, and then have only one implementation is overkill although I know some people will disagree. But I believe this is still a code smell none-the-less, because at then end of the day you have an interface with only 1 implementation. Say you are going to have more than one implementation later it will literally take you 10 seconds to change this back into an interface with 1 implementation with refactoring in eclipse. Simply copy your implementation code some where, extract the interface, change the current class to be the extracted interface, and put your copy code back in your project with something like InterfaceImp extends Foo on the top. Done. No need to overdo it at the start with maintaining some ghost interface.