Ranking Row Data Gateway, Table Data Gateway, Active Record, and Data Mapper by how tightly they couple domain/business logic to the database, where does each sit, and how does that coupling level affect your ability to unit-test business rules without a database?

## What coupling means here Coupling, in the context of these four patterns, means how tightly business logic is welded to the mechanics of talking to a database — and by extension, how much infrastructure you need running just to exercise a business rule in a test. - **Active Record** sits at the tightest end of that spectrum: the object holding domain state and business methods is the very same object with `save()`, `find()`, and `delete()` methods running SQL, so there is no seam at all between 'the thing with business rules' and 'the thing that talks to the database' — they're one class. - **Row Data Gateway and Table Data Gateway** sit in the middle: by design, neither one contains any business logic whatsoever, so whatever object does hold the business rules is necessarily a separate class that merely depends on the gateway to load and save data. That separation is a real testability improvement over Active Record, because the business-logic-holding object can, in principle, depend on a gateway interface rather than a concrete gateway, letting tests substitute a fake or in-memory implementation. But that seam has to be deliberately designed — nothing about using a gateway automatically produces it; a team can still write the business object to depend directly on a concrete gateway class, keeping most of the coupling problem intact. - **Data Mapper** sits at the loosest end: domain objects hold zero persistence knowledge by construction, so they can be built and exercised entirely in memory, with the mapper only entering the picture at the boundary of loading and saving, never inside the domain object itself. | Pattern | Position | Where the business rules live | |---|---|---| | Active Record | the tightest end | the very same object running SQL | | Row Data Gateway, Table Data Gateway | the middle | a separate class that depends on the gateway | | Data Mapper | the loosest end | domain objects with zero persistence knowledge | ## Why the spectrum exists This spectrum exists because **persistence ignorance** — the idea that a domain object shouldn't need to know it's ever going to be saved anywhere — is valuable exactly to the degree that a system has meaningful business logic worth protecting from that concern. The concept connects directly to hexagonal (ports-and-adapters) and onion architecture styles, where the domain core is meant to depend on nothing outward-facing, with persistence implemented as a replaceable adapter sitting behind a port the core defines. - A **Data Mapper-based domain object** is a natural fit for that core: it has no outward dependency to invert. - An **Active Record object**, by contrast, is simultaneously domain object and persistence adapter fused into one, which directly violates the dependency direction hexagonal architecture is built around — you cannot swap out or fake the persistence adapter without also touching the class that holds your business rules. ## The trade-off cuts both ways The trade-off is real, though, and cuts both ways. - Achieving Data Mapper's loose coupling costs the mapper classes, identity map, and unit-of-work machinery. - Achieving even the gateway patterns' partial win costs the discipline of defining and honoring an interface rather than reaching for a concrete gateway out of convenience. - Tight coupling isn't free of upside either — Active Record's fused design means less code to write and fewer places to look, which is a legitimate win when there's genuinely little business logic worth isolating. ## The failure mode The failure mode of tight coupling shows up concretely as **test suite composition**: a codebase built on Active Record tends to accumulate integration-style tests that spin up a real or in-memory database even for what ought to be a trivial rule check — 'does a 10% discount apply correctly above $100' shouldn't need a database at all, yet often does in an Active Record codebase, because the discount method lives on the same class as the SQL. This slows the test suite and makes tests more brittle, since database setup and teardown becomes part of every test's failure surface, not just the ones actually testing persistence. ## Where it shows up A common real-world adaptation shows this trade-off being managed rather than solved outright: Rails-style Active Record teams facing this exact testability pain frequently extract business rules into plain 'service objects' or 'form objects' that operate on already-loaded Active Record instances, effectively hand-rolling a partial version of Data Mapper's separation on top of Active Record rather than replacing the pattern wholesale — a pragmatic middle ground between the two ends of the coupling spectrum.