As a technical lead choosing among Row Data Gateway, Table Data Gateway, Active Record, and Data Mapper for a new service, what factors should drive the decision, and under what conditions would you deliberately mix more than one of these patterns within the same codebase?

## What drives the decision Choosing among these four patterns for a new service is a genuine **architectural decision, not a matter of taste**, and PoEAA itself frames them as a spectrum of complexity versus power rather than presenting one as universally correct. The deciding factors are, in practice: 1. **Domain complexity** — how much real business logic (validation, calculation, workflow) versus plain create/read/update/delete. 2. **Object-to-table shape** — does a domain concept map to one row, or to an aggregate spanning several tables, or an inheritance hierarchy. 3. **Testing needs** — does the team need to isolate business rules from infrastructure in fast unit tests, or is integration-level testing acceptable. 4. **Team size and skill** — can the team maintain a mapper layer, identity map, and unit-of-work correctly, or would that machinery mostly go unused and misunderstood. 5. **Expected trajectory** — is this module likely to stay simple, or is complexity coming. A reporting module with a handful of read-mostly lookup tables and no real business rules scores low on all of these and is well served by Table Data Gateway or Active Record. A billing module with proration rules, multi-table invoice aggregates, and behavior that genuinely needs isolated unit testing scores high on most of them and justifies Data Mapper's extra ceremony. ## The choice is per module The more advanced part of this decision, and the one that separates a principal-level answer from a senior one, is recognizing that the choice doesn't have to be made once for an entire system. In a modular monolith or microservice architecture, each module or service is already a natural unit for this decision: nothing requires the billing module and the reporting module to use the same persistence pattern internally, as long as the pattern stays an internal implementation detail that never leaks across the module's public API. - A caller of the billing module's public interface shouldn't be able to tell, from that interface alone, whether the module is built on Data Mapper internally. - A caller of reporting shouldn't be able to tell it's built on Table Data Gateway. This is exactly the kind of boundary that a module system — for example explicit module APIs in a modular monolith, or any well-enforced package/bounded-context boundary — is meant to protect. ## The trade-off The trade-off of allowing per-module variation against enforcing one pattern system-wide is **consistency and onboarding ease versus local fit**. A single system-wide pattern means any engineer moving between modules already knows how persistence works everywhere; per-module variation means each module pays only the cost its own complexity actually justifies, but asks engineers to understand which pattern is in play before making changes. The real risk isn't variation itself — it's variation without a stated reason, which is confusing regardless of whether the underlying technical choices were individually sound. ## Failure modes The failure modes at this level are **organizational as much as technical**. 1. **Forcing Data Mapper on every module**, including trivially simple ones, means paying mapper-class, identity-map, and unit-of-work overhead everywhere, slowing delivery on the modules that had no complexity to protect in the first place. 2. **Forcing Active Record everywhere** has the mirror-image problem: the complex modules inherit fat models, cascading save-order bugs, and untestable business rules that a more appropriate pattern would have avoided. 3. **Unmanaged drift.** A third, subtler failure mode is unmanaged drift rather than a deliberate decision at all: engineers on an Active Record codebase, feeling the testability pain of a fused domain-and-persistence class, independently start wrapping business logic in ad hoc 'service' classes around loaded Active Record instances, each built slightly differently, with no shared convention — an unplanned, half-finished, undocumented migration toward Data Mapper-style separation that nobody actually decided to make. ## Where it shows up A concrete real-world pattern that avoids this drift: teams document the choice explicitly, typically as a short architecture decision record naming which pattern each module or bounded context uses and why, paired with enforced module boundaries so the choice stays an implementation detail. That combination — genuine per-module fit, plus an explicit written rationale, plus an enforced boundary — is what lets a system deliberately mix these four patterns without the mixing itself becoming a maintenance liability.