As a tech lead reviewing a design that proposes composable Specification objects for every filtering and validation need across a large codebase, what trade-offs and failure modes would make you push back, and when is a simpler predicate/query-object approach the better call?

## What the abstraction actually costs At the architectural-review level, the Specification pattern's cost isn't abstract — it's measured in the same currency as any abstraction: - extra indirection a reader has to traverse to understand what a piece of code actually checks; - extra files and classes to navigate; - extra design surface (interfaces, combinators, factory wiring) that has to be learned by every engineer who touches the domain layer. That cost is worth paying when it buys back something concrete: - reuse across multiple call sites; - composability of independently meaningful business rules; - or the ability to reuse the exact same rule for both in-memory validation and repository-level query filtering. When a proposed specification buys none of those — a rule used in exactly one place, never combined with anything, never queried against — the abstraction is pure overhead, and I'd push the team toward a plain predicate, a private method, or (in languages with first-class functions) a lambda passed directly to a `filter` call. This is the single most common failure mode I'd flag in review: **"Specification-itis,"** where a team internalizes "DDD says wrap business rules in Specifications" as a blanket rule rather than a tool for specific situations, and ends up with dozens of one-line, single-use Specification classes that add navigation cost without adding a single byte of reuse value. ## Failure mode: compositional opacity at scale A second failure mode is compositional opacity at scale. Composable specifications are genuinely powerful for building complex eligibility rules from small primitives, but nothing about the pattern forces anyone to keep the resulting trees shallow or well-named. I've seen production incidents traced to a five-or-six-level-deep and/or/not tree built dynamically from configuration, where the only way to figure out which specific sub-rule caused a false result was to attach a debugger and step through composite after composite — because no one had built an explain()/failure-reason mechanism, and the tree's structure existed only implicitly in how the composition code was wired at startup. In review, I'd require that any composite specification beyond two or three levels deep either: - gets intermediate variables with domain names, so the tree structure is visible in source, not just in runtime object graphs; - or gets a reason-reporting mechanism so failures are diagnosable without a debugger session in production. ## Failure mode: straddling the validation/query boundary A third, and in my experience the most costly failure mode, is letting specifications straddle the validation/query boundary without discipline. As covered in the query-translation trade-off, not every isSatisfiedBy expression is mechanically translatable to SQL, and the mismatch between imperative in-memory logic and declarative query logic (including SQL's three-valued NULL semantics) means a specification that looks like a clean, reusable "source of truth" for both validation and selection can, in practice, either: - throw at query-translation time; - silently fall back to a full-table load; - or — worst of all — silently diverge in behavior between the two paths on edge-case (NULL-heavy) data. As a reviewer, I'd insist any specification used for repository-level selection be restricted to a genuinely declarative, query-translatable subset, be covered by an integration test against a real database (not just an in-memory fixture test), and be explicitly labeled if it's validation-only and must never be handed to a repository as a filter. ## Where the pattern genuinely earns its keep Beyond these mechanical failure modes, there's a genuine architectural trade-off worth naming explicitly to the team: Specification adds most value in domains with a rich, evolving rulebook that's consulted from multiple angles — - insurance underwriting; - loan eligibility; - promotions/pricing engines; - access-control policy evaluation — where the business rules themselves are a first-class part of the domain model that product owners and domain experts actually discuss and change independently of the surrounding workflow code. In more CRUD-shaped domains, where "business rules" are really just a handful of straightforward validations tightly coupled to one specific form or one specific query, the pattern's composability and reuse machinery mostly goes unused, and a repository method with a well-named parameter list, or a simple validator function, does the same job with less ceremony and a shallower learning curve for new team members. ## My practical review heuristic My practical review heuristic: I ask "how many distinct call sites will actually consume this rule, and will any of them need to combine it with another rule or translate it into a query?" | What comes back | The call | |---|---| | The honest answer is one call site, no combination, and no query need | I push back toward a plain predicate | | The answer is multiple call sites, real combination, or a genuine query-translation need | Specification is the right tool | And at that point I also insist on the guardrails above: - shallow, named composition; - explainability for composite failures; - an explicit line between query-safe and validation-only specifications, so the pattern's genuine value isn't undermined by its own failure modes as the codebase grows.