I have an interface to communicate with a DB (actually it is not a database, but this is to give a concrete example):

interface DbInterface{
    Result sendQuery(Query q);

And I am trying to improve reusability by separating specific components into individual projects:

  • App1, an application that requires access to a database
  • App2, an application that requires access to a database
  • DB1, a concrete implementation of DbInterface (let's say SQL)
  • DB2, a concrete implementation of DbInterface (let's say using some NoSql database)

How do you typically design such an architecture and where should DbInterface be located?

  • in one of the applications? but that means all other three component depend on that project to access the interface - does not sound right
  • in one of the DB implementations? same - does not sound right.
  • in both DB implementations? code duplication.
  • in a separate project, which would only contain that interface? seems abusive to include a dependency for one interface only.

For reference, this is Java + maven, but the issue is fairly generic I suppose.

  • As three people have already given you the right answer, I will write mine in a comment: a separate project. And that separate project is called X-API where X is whatever you want to call it. Remember that an API, event when it only has interfaces is a project nonetheless. Commented Sep 4, 2013 at 20:29

3 Answers 3


The interfaces are what you use to define a contract between the Applications and the implementation. That contract is usually managed by a middle project referred to as the API or SDK.

The application uses interfaces from the SDK, and the DB1 project implements those interfaces, but it's the SDK project that defines those interfaces.

enter image description here


I would personally go with the separate project. Pretty much every project I have worked on has had some kind of 'common' project/library that all others reference.

While it probably is overkill just for a single interface, it seems likely that there might similar cases in the future, and when that happens you already have a dedicated place to put them.

I don't know the ins and outs of your applications, but are there no helper classes etc that might be of benefit to both projects that could also go in a common project?

  • So a sort of company-toolbox project that contains the pieces that are typially reused. Not a bad idea.
    – assylias
    Commented Sep 4, 2013 at 15:12
  • This solution models JDBC type mentality, with JDBC being a common interface shared among applications (part of the JVM), and individual jar library files which implement each database type. Maybe this isn't Java, but I think this is an excellent approach regardless.
    – Neil
    Commented Sep 4, 2013 at 15:39

A separate project would be best in this scenario. Though now it will contain just a single interface, it may grow. Normally this type of project is called something like "API". There is no reason that a project such as this cannot contain some logic (for example, if you wanted to provide a facade on disparate API interfaces), but it should not be implementation specific.

Most applications should only have to rely on this API project as you should be coding to interfaces anyway. Only projects which tie in some sort of specific implementation will actually have to know about the API implementations. In modern applications that extensively use DI, the implementation is usually just a runtime concern.

Examples abound in the Java realm. JPA and Apache Commons Logging (or any other logging API) are a couple that you have probably already worked with.

As far as your comment "seems abusive to include a dependency for one interface only". I can see how this feels a bit awkward the first time you encounter it, but I would argue that it is more abusive to include dependencies you don't need in a project as you would be doing if you had to include the implementation to get only the interface.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.