What is the Table Module pattern for organizing domain logic, and in what situations does it fit better than Transaction Script or Domain Model?

## What Table Module is Table Module, one of Martin Fowler's three Patterns of Enterprise Application Architecture domain-logic patterns, organizes business logic **by database table** rather than by transaction or by domain concept instance. You create one class per table or view — say an `OrderTable` class — and that class's methods take a row or, more commonly, a whole in-memory record set as a parameter, and return computed results. A method like `CalculateTotalsFor(DataTable rows)` operates across an entire batch of order rows at once, rather than a Domain Model's approach of instantiating a separate Order object with its own identity for every row. This works hand in hand with a **Recordset** construct that behaves like an in-memory table — rows and columns, sortable and filterable — often produced directly by a SQL query, so there is almost no translation gap between what the database returns and what the business logic consumes. ## Why the pattern exists The pattern exists because certain platforms hand you a rich, navigable in-memory table structure essentially for free. The motivating case, and the one Fowler names explicitly, is Microsoft's COM and .NET tooling: ADO.NET's `DataSet` and `DataTable` give you sorting, filtering, relations, and data-binding to UI grids without writing any mapping code. Building a full Domain Model on top of that means paying an object-relational mapping cost the platform doesn't actually require, since the record set already is a convenient in-memory table. Table Module lets you attach business behavior directly onto that structure, keeping the platform's convenience while still giving business logic an organized home — grouped by table concept and reusable across multiple use cases — rather than scattering it across many one-off Transaction Scripts. ## The trade-off — convenience against weaker object semantics The trade-off is convenience and low mapping overhead in exchange for weaker object semantics. **On the plus side:** - no ORM cost on record-set-native platforms, - logic organized and reusable per table concept rather than duplicated per transaction, - and natural fit with tools that bind UI grids or reports directly to the record set. **On the minus side:** - there's no true object identity per row, so modeling polymorphic per-instance behavior — different order types behaving differently, for example — is awkward, since you'd need to branch on a type column inside the table class rather than override a method on a per-row object; - it's also harder to unit test in a fully isolated way compared to plain objects, since you're constructing and manipulating loosely typed rows and columns rather than calling typed methods on a domain instance; - and outside record-set-rich platforms, most mainstream OO languages — Java, Kotlin, modern C# with Entity Framework — don't have a first-class in-memory table type to hang Table Module methods off of, which is why the pattern is comparatively rare today outside some enterprise .NET and legacy VB6/classic-ASP.NET systems. ## How it fails A common failure mode is teams hand-rolling a fake record-set abstraction in a language that has no native one, adding real complexity for a benefit the platform was never going to give them in the first place. The opposite failure is sticking with heavy DataSet-driven Table Module code in modern .NET long after Entity Framework — a proper ORM enabling Domain Model — became the standard, well-supported approach; this legacy style tends to accumulate loosely typed row access like `row["ColumnName"]`, which causes runtime type errors and typo bugs that a domain object with strongly typed properties would have caught at compile time, and it's noticeably harder to unit test without either a database or a hand-built fake record set. ## Where it shows up, and how it sits between the other two In practice, Table Module shows up in classic ADO.NET, VB6, and classic ASP.NET WebForms applications built around DataSet and DataAdapter, where business logic classes operated directly on typed DataTables bound to UI grids. Positioned against the other two Domain Logic Patterns, it's a genuine middle ground: | Pattern | Where it sits | |---|---| | Transaction Script | the simplest, with no shared structure at all | | Table Module | adds organization by table while staying row-set-oriented with no per-row objects | | Domain Model | the richest, with per-instance objects, identity, and behavior, at the highest mapping and learning-curve cost | Recognizing which of the three a legacy codebase is using — and why it was a reasonable choice for its era's tooling — is often the first step in deciding whether a migration to Domain Model is actually worth the cost today.