Do Service and DAO Layers Need Interfaces? When to Omit Them in Spring Projects

A few days ago I encountered the question “Is it really necessary to add an interface to every Service and DAO class?” I previously answered briefly that it depends, and now, based on projects I’ve worked on and source code I’ve examined, I argue that when using a dependency‑injection framework such as Spring, interfaces are not required.

Reasons Not to Need Interfaces

Common arguments for adding interfaces to Service and DAO layers are:

It allows upper‑layer code (e.g., Controllers) to be written before lower‑layer logic is implemented.

Spring’s default AOP implementation relies on dynamic proxies, which require interfaces.

It enables multiple implementations of a Service.

In practice, none of these reasons hold up when a DI framework is used.

The first reason sounds reasonable for large teams that develop different layers separately, but most projects are organized by feature rather than by layer; a single developer often implements the full flow from Controller to DAO. Defining an interface in such cases adds work without benefit, and developers can simply write placeholder methods or rely on IDE auto‑completion.

The second reason is invalid because Spring can be configured to use CGLib for AOP, which does not require interfaces.

The third reason—multiple implementations—is rarely needed, and when it is, other techniques (e.g., profile‑based beans or separate modules) can replace the need for interfaces.

Project Structure and Interface Implementation

A typical layer‑based project structure looks like:

Controller

Service

Dao

If multiple implementations are not required, this structure works fine without any interfaces.

When multiple implementations are needed, two common approaches appear:

Add a new package inside the existing Service package, create a new implementation class, and adjust the configuration to inject the new bean.

Create an entirely new Service module (with its own package) that contains the new implementation, then modify the configuration to use that module.

The first approach is simpler because it only touches the package level, while the second requires managing both module and package levels and can introduce redundant code.

A hybrid solution combines the advantages of both: keep the interface in a separate module, have ServiceImpl and ServiceImpl2 modules with identical package structures, and select one implementation via dependency configuration. This way the interface module can even be removed if only one implementation is active.

Disadvantages of Not Using Interfaces

Not using interfaces eliminates a strong contract, reduces IDE assistance (e.g., quick generation of method stubs, compile‑time checks), and makes it harder to detect missing implementations. A less elegant workaround is to copy the original module and modify the copy for new logic.

Therefore, if a project truly requires multiple implementations and the number of implementations is significant, interfaces are recommended; otherwise, they can be omitted.

Summary

This article revisits the question of whether Service layers need interfaces, debunks the usual justifications, and presents practical guidance on when to use or skip interfaces in Spring‑based backend development.