Transaction Script Pattern

Also Known As

TL;DR

Explanation

Transaction Script (Martin Fowler, PoEAA) organises logic as a set of procedures — one function per business transaction. The procedure reads data, applies logic, and writes results. Simple, easy to understand, easy to trace. Best for: simple CRUD applications, scripting, reporting, and ETL. Problems at scale: duplicate logic across scripts, difficult to reuse, logic grows unwieldy as rules multiply. The contrast with Domain Model: Transaction Script = logic in procedures; Domain Model = logic in objects.

Common Misconception

Why It Matters

Common Mistakes

• Sticking with Transaction Script as the domain grows — recognise when duplication signals time to introduce a domain model.
• Long transaction scripts with 200+ lines — extract helpers but consider whether a domain model is needed.
• Business logic split between scripts and stored procedures — consolidate in one place.
• No service layer abstraction — transaction scripts directly calling SQL make testing difficult.

Code Examples

// Transaction script — appropriate for this simplicity:
function createUser(array $data): int {
    $pdo->prepare('INSERT INTO users (name, email) VALUES (?, ?)')
        ->execute([$data['name'], $data['email']]);
    return $pdo->lastInsertId();
}
// Fine for simple CRUD — no need for domain model complexity here

// Transaction script becoming unwieldy — time to refactor to domain model:
function processOrder(int $orderId): void {
    // 50 lines: fetch order, check inventory, apply discount rules,
    // calculate tax, charge payment, update inventory, send email,
    // update loyalty points, generate invoice...
    // Each rule duplicated in processReOrder(), processSubscriptionOrder()...
    // Signal: extract Order domain object with these methods
}

References

• ↗ https://www.martinfowler.com/eaaCatalog/transactionScript.html

Tags

Related Terms