Domain-Driven Design: Tackling Complexity in the Heart of Software

Selection (or Querying)
Validation tests an individual object to see if it meets some criteria, presumably so that the client
can act on the conclusion. Another common need is to select a subset of a collection of objects
based on some criteria. The same concept of 
SPECIFICATION
can be applied here, but
implementation issues are different.
Suppose there was an application requirement to list all customers with delinquent 
Invoices.
In
theory, the 
Delinquent Invoice Specification
that we defined before will still serve, but in
practice its implementation would probably have to change. To demonstrate that the 
concept
is
the same, let's assume first that the number of 
Invoices 
is small, maybe already in memory. In
this case, the straightforward implementation developed for validation still serves. The 
Invoice
Repository
could have a generalized method to select 
Invoices
based on a 
SPECIFICATION
:
public Set selectSatisfying(InvoiceSpecification spec) {
Set results = new HashSet();
Iterator it = invoices.iterator();
while (it.hasNext()) {
Invoice candidate = (Invoice) it.next();
if (spec.isSatisfiedBy(candidate)) results.add(candidate);
}
return results;
}
So a client could obtain a collection of all delinquent 
Invoices with a single code statement:
Set delinquentInvoices = invoiceRepository.selectSatisfying(
new DelinquentInvoiceSpecification(currentDate));
That line of code establishes the concept behind the operation. Of course, the 
Invoice
objects
probably aren't in memory. There may be thousands of them. In a typical business system, the
data is probably in a relational database. And, as pointed out in earlier chapters, the model focus
tends to get lost at these intersections with other technologies.
Relational databases have powerful search capabilities. How can we take advantage of that power
to solve this problem efficiently while retaining the model of a 
SPECIFICATION
? M
ODEL-DRIVEN DESIGN
demands that the model stay in lockstep with the implementation, but it allows freedom to choose
any implementation that faithfully captures the meaning of the model. Lucky for us, SQL is a very
natural way to write 
SPECIFICATIONS
.
Here is a simple example, in which the query is encapsulated in the same class as the validation
rule. A single method is added to the