Great question—let’s break this down based on your team’s specific context (Maven/Spring Boot/Java 8, migrating from JDBC Template to JPA Repositories, 20 DAOs + 50+ JpaRepos).

1. Is Removing the DAO Abstraction Layer Reasonable? #

The short answer: It depends on your current and future needs, but for most teams completing a full migration to JPA, it’s a valid and simplifying choice. Here’s why:

• The original purpose of the DAO layer was to abstract multiple data access strategies (JDBC, filesystem, JPA in your case). If you’ve fully migrated all JDBC and filesystem logic to JPA, and have no plans to add new data access technologies (e.g., NoSQL, external APIs for data) in the near future, the DAO layer becomes redundant. JpaRepository already provides a robust, Spring-managed abstraction for CRUD and custom queries—you don’t need an extra layer just to wrap it.
• Simplification wins: Removing the DAO layer cuts down on boilerplate code (no more empty DAO implementations that just delegate to JPA repos) and reduces cognitive overhead for your team. Service layers can directly interact with JpaRepository instances, keeping the architecture lean (controller → service → JPA repos).
• Caveats to consider:
  • If you anticipate needing to add new data access strategies later, or need to enforce cross-cutting concerns (global audit logging, caching, exception translation) across all data access operations, a thin abstraction layer (maybe renamed to Repository to align with JPA’s terminology) could still be useful. For example, you could create a custom BaseRepository interface that extends JpaRepository and adds shared logic, then have all your repo interfaces extend that.
  • Make sure to migrate any custom logic from your DAOs to JPA properly. Complex queries (multi-table joins, custom SQL) can be handled via @Query annotations, Specifications, or even Spring Data Query Methods. Avoid moving data access logic into the service layer—keep that focused on business rules, not how data is fetched.

2. How Does This Architecture Relate to Domain-Driven Design (DDD)? #

Your current onion architecture is already aligned with DDD’s core principles of separating concerns by layer, but the choice to remove the DAO layer impacts how you adhere to DDD’s Repository pattern:

• DDD’s Repository pattern explained: In DDD, Repositories are abstract interfaces defined in the domain layer (the core of the onion) that describe how domain entities are persisted. The actual implementation (e.g., JPA-based) lives in the infrastructure layer (the outer layer of the onion). This follows the Dependency Inversion Principle: domain/business layers depend on abstractions, not concrete infrastructure implementations.
• Directly injecting JpaRepository into Service layers: This skips the domain-layer abstraction. While it works for simpler applications, it couples your service layer (business logic) directly to JPA—a specific infrastructure technology. If you ever wanted to swap JPA for another persistence framework, you’d have to rewrite code in every service that uses JpaRepository.
• If you want to align with DDD: Instead of removing the DAO layer entirely, refactor it into domain-layer Repository interfaces. For example:
  • Define a UserRepository interface in your domain layer with methods like findByEmail(String email) (business-focused, not JPA-specific).
  • Create a JpaUserRepository implementation in your infrastructure layer that extends JpaRepository<User, Long> and implements the domain’s UserRepository interface.
  • Inject the domain UserRepository into your service layer, not the JPA-specific one.
• Middle ground: If you don’t need full DDD rigor right now, you can still keep things simple by using JPA repos directly, but consider wrapping them in a thin service-level abstraction if you start seeing repeated query logic across services.

Practical Migration Tips #

• Incremental transition: Instead of deleting all DAOs at once, start by migrating one DAO’s logic to a corresponding JpaRepository, then update the service to use the repo directly. Once all services are using repos, you can safely delete the DAO classes.
• Leverage Spring Data JPA’s features: Use query derivation, @Query, and Specifications to replace custom JDBC Template queries. For complex logic, consider using Spring Data Projections to fetch only needed fields.
• Handle cross-cutting concerns with AOP: If you need things like audit logs or exception handling, use Spring AOP to intercept JpaRepository methods instead of adding logic to a DAO layer.

内容的提问来源于stack exchange，提问作者Dave Ranjan