A codebase built its entire Service Layer in the operation-script style - each service method contains its own procedural business logic rather than delegating to domain objects. Over two years, the same 'is this customer eligible for expedited shipping' check has been copy-pasted into four different service methods and now disagrees in one of them. What does this indicate about how the Service Layer has scaled, and what are the practical remedies?

## How the same rule ends up in four places When a Service Layer is built entirely in the operation-script style, every use case's logic is written procedurally inside its own service method, with no structural mechanism forcing related use cases to share a rule even when they conceptually should. 'Is this customer eligible for expedited shipping' isn't owned by any one place — it's just a snippet of conditional logic that: 1. got typed into `placeOrder()`, 2. then copy-pasted (with small, well-intentioned tweaks) into `reorderPreviousCart()`, 3. then again into `adminOverrideOrder()`, 4. and again into a batch job's `bulkReship()` method. Each copy starts identical, but because there's no single implementation both/all call sites depend on, later bug fixes or rule changes only get applied wherever someone remembers to make them, and the copies silently diverge. This is not a hypothetical risk — in any codebase where 'copy the existing method and tweak it' is the easiest way to add a new use case, this kind of drift is close to inevitable given enough time and enough people. ## Why this is a scaling problem, not a one-off bug The reason this specifically indicates a scaling problem with the operation-script style (rather than being a one-off bug) is that operation script has no natural place for shared rules to live. In a domain-facade design, 'expedited shipping eligibility' would be a method on a `Customer` or `ShippingPolicy` domain object, and every service method that needs the answer calls that one method — there's structurally only one implementation to diverge from. In pure operation script, the equivalent shared logic has to be deliberately factored out into something (a private helper, a static utility, a small rules class) or it defaults to being duplicated, because the natural unit of code organization in that style is 'one service method equals one self-contained procedure.' ## The practical remedies The practical remedies fall into two categories, and teams don't have to fully commit to rewriting the whole Service Layer as rich domain facade to apply them. - **The lighter-weight fix** is extraction without object-orientation: pull the shared conditional logic into a private helper method within the service class, or — if it's needed by multiple service classes — into a small stateless policy or rules class (e.g., a `ShippingEligibilityPolicy` with a single `isEligibleForExpedited(customer, order)` method) that every relevant service method calls. This preserves the operation-script style everywhere else but establishes exactly one authoritative implementation for this particular rule, which is really a targeted, minimal step toward domain-facade for just the piece of logic that turned out to need reuse. - **The heavier fix** is to actually move the logic onto the relevant domain object as a proper method, which additionally gets you the domain-facade benefits of being unit-testable in isolation and being harder to accidentally duplicate again, since it now naturally belongs to the object it concerns rather than floating as a free-standing rule multiple services could each reimplement. ## Finishing the job: delete the old copies Either remedy needs to be paired with actually refactoring the existing divergent call sites to depend on the new single implementation — simply adding a shared helper without deleting the old copies doesn't fix anything, and is a common half-measure that leaves five implementations instead of four. Once unified, adding a focused regression test (or a set of parameterized tests covering the known edge cases that had caused the four copies to diverge in the first place) pins the now-single behavior, so a future change to eligibility rules can't silently regress in one call path while being correctly applied everywhere else, which is exactly the failure mode that got the team into this situation. ## How teams usually notice it A concrete real-world pattern this maps to: teams building on frameworks like Spring often notice this exact issue by running full-text search across the codebase for a magic number or string threshold (say, a '$500' free-shipping cutoff) and finding it hardcoded in three or four different `@Service` classes with slightly different comparison operators (>, >=) — a very common and detectable symptom of operation-script duplication that a simple grep for a business constant can surface, which is itself often how teams first discover the problem rather than through a subtler code review. ## The sibling symptom Beyond duplication, a second, related symptom of operation-script strain at scale is **service-class bloat**: because there's no natural home for shared logic, teams often respond by cramming more and more marginally-related use cases into the same service class just because it already has some convenient private helper methods nearby, producing a wide 'god service' class handling dozens of unrelated concerns, which slows down code review, increases merge conflicts, and makes the class hard to reason about or split later, since its internal helpers are entangled across use cases that don't actually belong together.