Specifications are traditionally described as having three uses: validation, selection, and construction-to-order. What does 'construction-to-order' mean, and how does it differ from just validating an object after it's built?

## The three roles one specification plays Eric Evans, in the original Specification pattern write-up (later expanded by Martin Fowler), identifies three distinct roles a single specification object can play, all backed by the same `isSatisfiedBy` predicate but consumed differently depending on the caller's intent. 1. **The first, validation**, is the most familiar: given an already-existing candidate object, ask whether it currently satisfies the rule — `orderSpec.isSatisfiedBy(existingOrder)`. 2. **The second, selection**, uses the specification to filter a collection down to matching members, either in memory (`orders.filter(spec::isSatisfiedBy)`) or, more powerfully, translated into a query executed by a repository so the filtering happens in the database rather than after loading every row into memory. 3. **The third and least obvious, construction-to-order**, inverts the direction of use entirely: instead of checking an object that already exists, you hand the specification *to a factory or builder* as an input, and the factory reads the specification's parameters to construct a brand-new object that is guaranteed to satisfy it from the moment it exists, rather than being built first and checked second. ## What construction-to-order looks like Concretely, imagine a specification like `LoanEligibilitySpecification(minIncome, maxDebtRatio)` used for validation against existing applicants. Construction-to-order would use the *same* specification object, but instead pass it to a `TestDataFactory` that reads `minIncome` and `maxDebtRatio` off the specification and generates a synthetic applicant whose income and debt ratio are deliberately set within those bounds — producing an object that is correct by construction, with zero chance of generating an invalid one and then discarding it. Another common real scenario: a scheduling system where a `MeetingSlotSpecification` (business hours, no existing conflicts, room capacity >= N attendees) is normally used to validate a proposed slot, but a "find me a valid slot" feature instead hands that same specification to a slot-generator that walks the calendar and constructs a `TimeSlot` object it knows in advance will satisfy the specification, rather than generating arbitrary slots and validating each one after the fact. ## Why it earns its own name Why does this distinction matter enough to name separately? Because build-then-check and build-to-satisfy have very different cost profiles when construction is expensive, random, or combinatorially large. - If constructing a candidate object is **cheap** (a plain in-memory object with a few fields), build-then-validate-then-discard-on-failure is perfectly fine and often simpler to implement — you just call the constructor and check the result. - But if construction involves **expensive** work — hitting a database, calling an external allocation API, running a simulation — repeatedly building throwaway candidates until one happens to satisfy the specification is wasteful and can even be infeasible if valid candidates are rare (imagine randomly generating credit applicants until one happens to qualify for a loan — the acceptance rate could be near zero). Construction-to-order pushes the specification's constraints *into* the generation logic itself, so the factory only ever produces valid objects. ## The trade-off: encapsulation The trade-off is that construction-to-order requires the factory to actually understand and use the specification's internal parameters, not just its opaque `isSatisfiedBy` predicate — which means the specification can no longer be a fully black-box boolean function; the factory needs structured access to its bounds/thresholds. This partially breaks encapsulation: a specification designed purely for validation (an opaque `isSatisfiedBy` closure) often can't be reused for construction-to-order without redesigning it to expose its parameters in a structured, factory-consumable way. Teams that only ever need validation and selection frequently skip implementing construction-to-order entirely, and that's a reasonable choice — it's the least commonly needed of the three uses in ordinary CRUD-style business applications, and shows up more often in domains involving generative or combinatorial construction: - test-data generation; - constraint-based scheduling; - procedural content generation; - configuration solvers that need to synthesize an object meeting a set of constraints rather than merely check one against them. ## The over-reach to watch for A failure mode worth flagging: teams sometimes reach for construction-to-order where a much simpler default-plus-override builder would do, adding a layer of specification-driven generation to a case where a straightforward parameterized factory method (`Applicant.qualifying(minIncome, maxDebtRatio)`) is more direct — construction-to-order earns its complexity when the constraints are the same constraints already validated elsewhere and you want a single specification object as the sole source of truth for both checking and generating, not as a way to avoid writing a normal constructor.