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

Specification
In all kinds of applications, Boolean test methods appear that are really parts of little rules. As long
as they are simple, we handle them with testing methods, such as 
anIterator.hasNext()
or
anInvoice.isOverdue()
. In an 
Invoice
class, the code in 
isOverdue()
is an algorithm that
evaluates a rule. For example,
public boolean isOverdue() {
Date currentDate = new Date();
return currentDate.after(dueDate);
}
But not all rules are so simple. On the same 
Invoice_class,_another_rule,_anInvoice.isDelinquent()_would_presumably_start_with_testing_if_the_Invoice'>Invoice
class, another rule,
anInvoice.isDelinquent()
would presumably start with testing if the 
Invoice
is overdue, but
that would just be the beginning. A policy on grace periods could depend on the status of the
customer's account. Some delinquent invoices will be ready for a second notice, while others will
be ready to be sent to a collection agency. The payment history of the customer, company policy
on different product lines . . . the clarity of 
Invoice
as a request for payment will soon be lost in
the sheer mass of rule evaluation code. The 
Invoice
will also develop all sorts of dependencies on
domain classes and subsystems that do not support that basic meaning.
At this point, in an attempt to save the 
Invoice
class, a developer will often refractor the rule
evaluation code into the application layer (in this case, a bill collection application). Now the rules
have been separated from the domain layer altogether, leaving behind a dead data object that
does not express the rules inherent in the business model. These rules need to stay in the domain
layer, but they don't fit into the object being evaluated (the 
Invoice
in this case). Not only that,
but evaluating methods swell with conditional code, which make the rule hard to read.
Developers working in the logic-programming paradigm would handle this situation differently.
Such rules would be expressed as 
predicates
. Predicates are functions that evaluate to "true" or
"false" and can be combined using operators such as "AND" and "OR" to express more complex
rules. With predicates, we could declare rules explicitly and use them with the 
Invoice
. If only we
were in the logic paradigm.
Seeing this, people have made attempts at implementing logical rules in terms of objects. Some
such attempts were very sophisticated, others naive. Some were ambitious, others modest. Some
turned out valuable, some were tossed aside as failed experiments. A few attempts were allowed
to derail their projects. One thing is clear: As appealing as the idea is, full implementation of logic
in objects is a major undertaking. (After all, logic programming is a whole modeling and design
paradigm in its own right.)