Separating database access from business decisions

A small application begins with a screen that reads a database row, checks a condition and updates a field. As the application grows, the same pattern appears in imports, background jobs and other screens. Eventually a change to one business rule requires finding many slightly different versions of the same decision mixed with database calls.

Separating database access from business decisions can make that system easier to maintain. The boundary gives persistence code responsibility for reading and writing data, while the application expresses what the business is trying to do. The benefit comes from a clear allocation of responsibility, not from adding layers for their own sake.

A poorly chosen boundary can make matters worse. It may hide expensive queries, remove useful database guarantees or encourage tests that pass against a simplified fake while the real system behaves differently. A practical design preserves the facts developers need to reason about correctness and performance.

Begin with a business operation that keeps changing

Choose a concrete operation, such as releasing a production job. Write its purpose in ordinary language: verify the required approval and material conditions, record the release and make the accepted result available to the next process. This description should make sense without naming a database table or a user-interface widget.

Then inspect where that operation is implemented. A form may check approvals, an import may skip that check, and a scheduled process may use an older interpretation of material availability. The problem is duplicated decision logic, even if each piece of SQL is individually correct.

Identify what the decision needs to know and what it must change. Some information can be read as a stable input to a calculation. Other information must remain protected by a database transaction while the decision is accepted. A useful boundary must retain that distinction.

Avoid beginning with a goal such as “make every database interchangeable”. Portability may matter, but it is not always the business problem. A focused boundary that supports one changing workflow can provide more immediate value than a universal abstraction that conceals the database features the application actually relies on.

Assign responsibilities explicitly

Persistence code handles the mechanics of accessing stored information: parameter binding, mapping rows, managing query execution and translating expected storage failures into useful application outcomes. Business logic decides what the information means for the operation being performed.

An application service can coordinate the workflow. It gathers the needed information, invokes the relevant decision rules and owns the point at which accepted changes are committed. The exact structure depends on the application, but the responsibilities should be recognisable during review.

The Data Mapper pattern is one reference for keeping in-memory domain objects independent of database storage details. It is a design option rather than a requirement for every application. Simpler applications can use more direct patterns when those patterns remain clear and maintainable.

The key test is whether changing a business rule requires editing unrelated persistence mechanics, and whether changing a storage detail requires rewriting the decision itself. Complete independence is rarely possible, but accidental coupling can be reduced substantially.

Design operations around useful meanings

An interface that exposes only generic create, read, update and delete methods can be too weak to express an important operation. “Save job” does not say whether the job is being drafted, released, completed or corrected. Those actions can have different preconditions and permission requirements.

Conversely, naming a method release_job does not guarantee that it enforces release semantics. Its contract should identify the required inputs, accepted outcome and meaningful failures. State whether it performs the whole transaction or participates in one owned by its caller.

Read operations need useful contracts too. “Find releasable jobs for this workshop” is different from “return every job and let the caller filter”. The former can express scope, ordering and pagination while keeping query execution efficient. The latter may load far more data than the caller expects.

Do not place every possible report behind the same entity-loading interface. Reporting often needs projections or aggregates rather than editable domain objects. A clear read model can serve those needs without forcing the application to construct a large object graph solely to display three columns.

Work through a job-release boundary

This is an illustrative example. A workshop job requires an approved drawing revision and a confirmed material allocation before it can be released. Assume those facts and the release record are held in one database, and release must be accepted atomically.

A useful application operation receives the job identity and an authenticated actor context. It checks the actor’s permission, obtains the relevant current state under the chosen transaction policy, evaluates the release conditions and records the accepted release. It returns an explicit outcome rather than merely reporting that an update statement ran.

The persistence boundary might provide a purpose-built operation that loads and protects the release state, plus a write operation that applies the expected transition. Alternatively, the application service may issue well-contained database commands directly within its transaction. Either structure can work if the responsibilities remain visible.

If material can be changed concurrently, a check performed before the acceptance transaction may no longer be valid. Moving that check into a “business layer” does not protect it. The boundary must allow the application to preserve the database guarantees needed for the decision.

Keep transaction ownership visible

A workflow that calls three persistence methods can still require one transaction. If each method opens and commits its own transaction, the workflow may leave partial results when the third step fails. The interface should not make that behaviour a hidden implementation detail.

Choose an owner that understands the complete acceptance boundary. Lower-level helpers can manage statements and resources while participating in that boundary. Where a method deliberately commits independently, its contract should explain why that is correct for the business operation.

Read consistency also matters. Two separately executed queries may observe different states if other work commits between them, depending on the database and isolation level. A decision that requires a coherent view must obtain that view deliberately. Returning ordinary objects does not make the underlying reads simultaneous.

External effects remain separate. An email or machine instruction usually cannot be undone by rolling back the database. The application workflow needs a delivery and recovery policy rather than assuming every operation behind an interface shares the same transaction semantics.

Keep mapping separate from interpretation

Mapping converts a stored representation into a form the application can use. It may turn database rows into typed objects, assemble related values or translate a storage format. Business interpretation decides whether those values permit an action or imply a particular outcome.

For example, converting a stored timestamp to an application time type is a mapping concern. Deciding whether a job is late under a workshop’s calendar is a business rule. Combining them in a generic row-conversion helper makes it difficult to see which policy is being applied.

Validation can exist at several boundaries for different reasons. A mapper should reject data it cannot interpret safely. Business logic should reject an invalid operation. Database constraints should preserve applicable invariants for every writer. The same field can participate in all three without making the responsibilities identical.

When legacy storage uses unclear codes, avoid scattering translation throughout the application. Keep an explicit mapping close to the persistence boundary and document unresolved meanings. A cleanly named object should not conceal that its source value was guessed from ambiguous historical data.

Translate failures without erasing their meaning

Database errors often need interpretation before they reach a user. A unique-key conflict might mean an operation identifier has already been accepted, or it might reveal a genuine duplicate business key. A general “save failed” response loses information the caller may need for recovery.

Define expected outcomes for each operation. A concurrency conflict, a failed business precondition and an unavailable database should remain distinguishable. The application can then decide whether to reload, ask for a revised decision, retry safely or report an outage.

Do not treat every exception as a reason to repeat the entire operation. A commit response can be uncertain, and an external effect may already have occurred. Retry policy belongs with an understanding of the operation’s identity and duplicate-handling rules.

Keep technical diagnostics available to authorised maintainers without exposing raw database details to ordinary users. A correlation identifier and a meaningful message can connect the two views. Avoid leaking credentials, confidential parameters or internal schema details through an unfiltered exception page.

Avoid hiding query cost behind convenient properties

A domain object can look like an ordinary in-memory structure while loading more data whenever a property is accessed. A loop over jobs may therefore execute another query for every customer or component. A clean interface is not useful if it makes the cost of ordinary operations impossible to anticipate.

State which relationships are already loaded and which operations may access the database. For list screens, provide an appropriately shaped query result rather than relying on repeated lazy loading. For editing workflows, load the information the decision requires without bringing unrelated history into memory.

Avoid returning an unbounded query object from a supposedly finished read operation unless the interface deliberately exposes that behaviour. Callers may compose filters that execute later under a different connection or permission context. This can blur ownership of both performance and access control.

Measure representative operations at the boundary. Query count, elapsed time and returned row count can help detect a change that turns one planned query into many small requests. Performance tests should reflect actual workflows rather than asserting that every implementation must issue an arbitrary fixed number of statements.

Use different tests for rules and persistence

Pure decision logic can often be tested with small in-memory examples. A rule deciding whether a release is permitted should have cases for missing approval, insufficient allocation and already released work. These tests can be fast and easy to understand because they focus on the decision.

Persistence requires integration tests against the relevant database behaviour. Constraints, transactions, null semantics, collation and generated identifiers may differ from a simple in-memory fake. A fake that stores objects in a list cannot prove that the production query or transaction works correctly.

Contract tests can help connect the layers. Run a defined set of observable behaviours against the real implementation, and ensure any test double used elsewhere follows the parts of that contract it claims to model. Mark its limitations rather than assuming it is a miniature database.

The most valuable tests cross failure boundaries. Verify that an unsuccessful release leaves no partial accepted change and that a concurrent attempt produces the expected conflict. A collection of tests confirming that methods call other methods can miss these business outcomes entirely.

Let database capabilities remain available where needed

An abstraction should not force every operation into the weakest common behaviour shared by all imaginable databases. Efficient aggregation, locking, bulk loading or specialised indexing may be important to the actual system. Hiding those capabilities can create slow or unreliable substitutes in application code.

Use a boundary that contains database-specific implementation where practical while still exposing the required semantics. A method can promise an atomic conditional update without exposing every SQL clause to its caller. Its implementation can use the database’s supported mechanism and prove that behaviour through integration tests.

Be honest about portability. If an operation depends on a particular isolation behaviour or text comparison rule, replacing the database requires verifying that contract. An interface reduces the area that must change; it does not make different products semantically identical.

Document these dependencies close to the operation. Future maintainers should be able to distinguish a deliberate use of a database guarantee from an incidental implementation choice. That knowledge helps them optimise or migrate without weakening correctness.

Introduce the boundary gradually

A working application rarely needs a complete rewrite to improve responsibility boundaries. Choose one problematic workflow, identify its duplicated rules and place those rules under a clear owner. Move or encapsulate the necessary persistence code while preserving the accepted behaviour.

Use a small set of before-and-after examples. Confirm that the new path accepts the same valid operations, rejects the same invalid ones and improves any intentionally corrected defect. Include import and background paths so the redesign does not protect only the main screen.

Avoid wrapping every existing method in another method without changing responsibility. That adds indirection while leaving the original decisions scattered. A useful refactor should make a specific future change easier to locate and reason about.

Keep old and new access paths under observation during transition. If both can write the same records, verify that they preserve the same constraints and transaction rules. Retire the obsolete path deliberately rather than leaving an undocumented alternative that future work may accidentally revive.

Give business reviewers something concrete to assess

People commissioning software do not need to approve a particular class hierarchy. They can review the operation’s conditions, outcomes and failure behaviour. A short acceptance table using familiar job examples is often more useful than an architectural diagram alone.

Ask maintainers to explain where each rule is implemented and which other entry points use it. If the answer depends on staff remembering to copy logic into a new import, the boundary is not yet doing enough. If every minor report requires changes to a complex shared framework, it may be doing too much.

The data dictionary helps establish shared meanings for the inputs and outputs. The application boundary then makes those meanings operational: it defines what can be requested, what will be checked and what result counts as accepted.

Judge the design by change and failure behaviour

A good boundary makes an important business change easier to implement consistently. It also makes failures easier to explain: the operation was rejected for a stated reason, conflicted with another accepted change or could not complete because a dependency was unavailable.

For a small Australian business, these outcomes matter more than the number of software layers. Start with a workflow where duplicated rules, partial saves or unexplained query behaviour are causing practical trouble. Improve the allocation of responsibility and verify the result with representative cases.

Database access and business decisions remain closely connected, but they need not be tangled together. A deliberate boundary keeps persistence mechanics contained, makes decision rules visible and preserves the transactional and performance guarantees the operation needs.

---

Source basis: original KEVOS editorial analysis of Data Accessor and Active Domain Object discussions in the supplied Data Access Patterns (2003), with the linked Data Mapper reference used for terminology. The job-release scenario is illustrative and does not describe a KEVOS implementation or client engagement.