Separation of Business Logic and Data Access

The main value of DAO is not “more classes.” It is clearer ownership. Business logic should decide what the system means. Data access code should decide how that meaning reaches storage.

What Belongs In Business Logic

Application and domain services should own decisions such as:

• whether an operation is allowed
• what counts as a valid state transition
• how workflows are sequenced
• which persistence operation is required next

These are business questions, not query questions.

What Belongs In Data Access

DAOs should own:

• query shape
• persistence technology interaction
• record or entity mapping
• translation of low-level persistence failures into boundary-level exceptions

That separation keeps services from turning into a mixture of business policy and storage plumbing.

A Useful Boundary Test

If a service method is filled with SQL strings, session APIs, criteria builders, or row-mapping code, persistence has leaked too far upward.

If a DAO decides whether a discount is valid or whether an order may ship, business logic has leaked too far downward.

Why The Split Helps

A clean DAO boundary improves:

• testability, because services can be tested with fake persistence boundaries
• maintainability, because query changes stay localized
• review quality, because business rules and storage rules are easier to inspect separately
• migration safety, because persistence changes do not automatically spill through every service

Where Teams Overdo It

DAO separation becomes counterproductive when:

• every trivial CRUD call gets wrapped with no additional clarity
• the DAO mirrors table structure more than application needs
• services still know too much about transaction and query details
• the extra layer exists only because “all enterprise apps have DAOs”

The goal is not maximum layering. The goal is clean responsibilities.

Design Review Questions

When reviewing the separation between business logic and DAO code in Java, ask:

• Can I understand the business decision without reading SQL?
• Can I change the query without rewriting service policy?
• Are transaction boundaries owned in the right place?
• Does the DAO API reflect business use cases or raw table operations?

A good DAO split makes each layer easier to reason about. A bad one simply moves boilerplate around.