Another case for Specifications

Yesterday I've started to hold my third week of courses, introducing people to Enterprise Application Design and Development using the wonderful Hibernate and Spring.

Using, as a reference, the well known Patterns Of Enterprise Application Architecture book, I've came across this sentences:

One of the hardest parts of working with domain logic seems to be that people often find it difficult to recognize what is domain logic and what is other forms of logic.
...
A good example of this is a system I was told about that contained a list of products in which all the products that sold over 10 percent more than they did the previous month were colored in red. To do this the developers placed logic in the presentation layer that compared this month's sales to last month's sales and if the difference was more than 10 percent, they set the color to red.

The trouble is that that's putting domain logic into the presentation.

Suddenly, I said : "Specifications, here, are at their best!"

Create a generic IncreasingSaleSpecification interface, implement it for your particular case and apply for determining the color of the product in your view!

Doing so:

• Business logic remains in your domain (into your Specification).


• Your view implements no business logic.


• You can implement new increasing sale specifications and simply change on the fly the behaviour defining when your products should be displayed in red.

Amazing!