Data Source Patterns

## What an Active Record object is The **Active Record** pattern, as codified in Martin Fowler's *Patterns of Enterprise Application Architecture*, describes an object that wraps one row of a database table and puts both the data and the logic to read and write that row on the same class. Concretely, a class like `Product` has: - **instance fields** mirroring the table's columns (`name`, `price`, `sku`); - **instance methods** like `save()`, `update()`, and `delete()` that run the corresponding SQL for that specific row; - **class-level or static finder methods** like `Product.find(id)` or `Product.findAll()` that query the table and return fully-populated instances. Any business rules that apply to a product — say, a discount calculation or a validation that price can't be negative — typically live as additional instance methods on the very same class. There is no separate layer standing between the object a developer manipulates in memory and the row that object represents in the database. ## Why it exists This pattern exists to minimize indirection. When a domain concept maps cleanly onto a single table, and the business logic attached to it is modest, introducing a separate mapping layer is pure overhead: extra classes, extra configuration, extra places to look when tracing a bug. Active Record collapses domain representation and persistence into one place so a developer reading the `Product` class sees everything about how a product behaves and how it's stored in one file. This is precisely why it became the default in frameworks aimed at getting CRUD-heavy applications running quickly: - **Ruby on Rails'** ActiveRecord ORM, most famously; - **PHP's Laravel** (Eloquent), later adopted in similar form; - **Django's** model layer, more loosely. ## The trade-off The trade-off is **coupling**. Because `save()` and `find()` are literally methods on the domain object, that object cannot exist, in any meaningful sense, independent of a database connection and a schema. Business logic that lives alongside those methods inherits that dependency: - you cannot easily construct a `Product` in a unit test and exercise its discount-calculation method without either running against a real (or in-memory) database or mocking out the persistence methods on the very class you're testing; - the class also violates single-responsibility in the classic sense — it has at least two reasons to change: a change to a business rule, and a change to the database schema. For a simple domain this rarely bites; for a growing one, it does. ## Failure modes 1. **The 'fat model' problem.** In production, the most common failure mode is what practitioners call the 'fat model' problem: as an application grows, more and more logic gets bolted onto the Active Record class because it's the path of least resistance — it's already there, already has the data loaded, and adding one more method is easier than designing a new collaborator. Over time a class meant to represent one row in one table accumulates validation rules, notification logic, formatting helpers, and authorization checks, becoming hundreds of lines that mix unrelated concerns and resist safe refactoring, since so much of the codebase reaches into it directly. 2. **The second table.** A second, related failure mode surfaces when the domain concept the class represents doesn't actually correspond to one table any longer — for instance once an `Order` needs line items from a second table — and developers either bolt ad hoc loading code onto the `Order` class or begin manually wiring multiple Active Record objects together, both of which erode the pattern's original simplicity. ## Where it shows up A concrete real-world illustration: Ruby on Rails applications are built around ActiveRecord by default, and the well-documented 'fat model, skinny controller' guidance that Rails teams eventually adopt is a direct response to this exact failure mode — pushing logic out of Active Record classes into separate service or concern objects once a model's responsibilities outgrow a single row's worth of behavior. The pattern itself isn't wrong; it's a deliberate trade of long-term flexibility for short-term simplicity, and understanding when that trade stops paying off — usually when business logic complexity or the object's table-shape stops being simple — is the actual skill being tested when this pattern comes up in an interview.