As a system's business logic grows more complex over time, how would you decide whether — and how — to migrate domain logic from a Transaction Script style toward a Domain Model, and what does that migration actually cost?

## The signals that justify a migration The decision to migrate should rest on concrete, observable signals rather than architectural fashion. **Four signals matter in practice:** 1. repeated duplication of the same business rule across more than one script, with any observed divergence between the copies being a strong red flag; 2. growing method length and cyclomatic complexity in the scripts touching a given area; 3. a rising rate of incidents where a rule was changed in one place but not another that also needed it; 4. and, most tellingly, a conditional chain branching on a type or category field that keeps growing as new variants are added — the classic case being an if/else or switch on a 'payment type' or 'account type' field, duplicated in more than one script. That last signal is the textbook invitation to **replace conditional logic with polymorphism**, a piece of general object-oriented wisdom that applies directly here. ## Migrating incrementally instead of by rewrite Once those signals appear, the mechanics of migration matter as much as the decision itself. A big-bang rewrite of the whole logic layer, run in parallel with the live system, is a well-known failure pattern: it takes months, the two systems inevitably drift on business rules during that window because nobody can keep every rule change synchronized across both, and the project risks being abandoned or shipped with regressions because the old tangled logic was never pinned down before the rewrite began. The safer approach borrows the **Strangler Fig** idea and applies it at the domain-logic level rather than the service level: 1. pick the single rule cluster causing the most pain; 2. write characterization tests around its current behavior first — tests that pin down what the system actually does today, quirks and all, rather than what it 'should' do — so the extraction step can be verified as behavior-preserving; 3. then extract a small object owning that rule; 4. have the existing Transaction Scripts delegate to it instead of implementing the logic inline; 5. verify against the characterization tests, and move on to the next cluster. Over time this produces a partial, targeted Domain Model around the subdomains that genuinely earned the investment, while simple CRUD areas remain untouched Transaction Scripts — an architecture Fowler explicitly endorses: it is entirely possible, and often correct, to use Transaction Script for some parts of a system's logic and Domain Model for others. ## Why this is really a calibration problem Why this matters is really a calibration problem. Waiting until scripts are completely unmanageable before reacting, and over-engineering greenfield code with a rich model nobody needs yet, are both costly failure modes at opposite ends of the same mistake: investing out of proportion to actual, observed complexity rather than fashion or fear. This mirrors evolutionary-architecture and YAGNI thinking more broadly — decisions are best made at the last responsible moment with real evidence in hand, and reversibility, via characterization tests plus incremental extraction, matters more than getting a hypothetical 'final' design exactly right on day one. ## What the migration costs The migration itself has real, named costs on both sides. **The benefit:** future rule changes localize to one object instead of touching N scripts, which reduces the defect rate caused by drift and enables genuine reuse and polymorphism going forward. **The cost:** - introducing mapping complexity — an ORM or repository layer for the newly extracted objects, since previously the scripts talked to the database directly through a simple Gateway; - plus a real learning-curve tax for engineers unfamiliar with rich OO domain modeling, including how to draw aggregate boundaries and enforce invariants without accidentally recreating an anemic model during the extraction; - there's also a short-term velocity hit while characterization tests and extraction happen alongside ongoing feature work; - and a genuine risk of doing the migration badly: extracting objects that still don't own their invariants, or drawing an aggregate boundary that's too large (a new god-object) or too small (chatty, inefficient cross-object calls). Because of this, the migration itself benefits from domain expertise — techniques like event-storming or close collaboration with domain experts to establish a shared vocabulary help find the right boundaries rather than guessing. ## A concrete scenario A concrete scenario makes this tangible: a payments platform starts with a simple `processTransaction()` Transaction Script handling card payments. Over several years, different teams bolt on branches for ACH transfers, wire transfers, multi-currency FX conversion, fraud-hold rules, and partial refunds, all inside the same script or its close relatives. A senior or staff engineer recognizing the drift-and-god-method signals would carve out a `PaymentMethod` hierarchy — `CardPayment`, `AchPayment`, `WireTransfer` subclasses, each owning its own validation and settlement behavior — behind characterization tests, migrating one payment type at a time, while deliberately leaving genuinely simple reporting queries as untouched Transaction Scripts. That's the coexistence architecture Fowler describes in practice, not a wholesale rewrite chasing an ideal 'correct' design.