Do Service and DAO Layers Need Interfaces? A Practical Discussion for Java Backend Projects

When asked whether every Service and DAO class should declare an interface, the author initially answered "it depends" but later argues that in projects using dependency‑injection frameworks such as Spring, interfaces are often unnecessary.

The three traditional reasons for defining interfaces are: (1) allowing upper layers to code against a contract before lower‑level logic is implemented, (2) Spring’s default AOP implementation relies on dynamic proxies which require interfaces, and (3) enabling multiple implementations of a Service.

The author refutes each point: developers can write placeholder methods instead of interfaces; Spring can use CGLib proxies to avoid interfaces; and most projects rarely need multiple Service implementations, so the added complexity offers little benefit.

A recommended top‑down development flow is described: first write Controller code and invoke Service methods, let the IDE generate the missing classes and methods with TODO comments, then gradually fill in the business logic based on those placeholders.

Regarding AOP, while Spring’s default proxy mechanism uses interfaces, it can be switched to CGLib, which works without interfaces.

Typical project layer structure: Controller → Service → Dao.

If multiple implementations are required, a possible structure is:

Controller

Service (interface package)

ServiceImpl (implementation package)

Dao

Alternative approaches include adding a separate Service module for each implementation or using module‑level selection to choose between ServiceImpl and ServiceImpl2 at build time.

Not using interfaces has drawbacks: lack of a strong contract makes IDE assistance weaker, and copying code to new modules becomes a clumsy way to handle multiple implementations.

In summary, interfaces are useful when a project truly needs multiple Service implementations; otherwise, with modern DI frameworks, they can be omitted to reduce boilerplate.