Implement Business Rules using Grails (Part 1)

General

Implementing business rules can be a tedious and error-prone task in application development. Business rules are often ambiguously defined and recorded. Since implementing business rules is usually a major task in each project, this can introduce a significant risk to the success of your Grails application.

We assume the following three main types of business rules:

• constraint rules
• change event rules
• authorization rules

Constraint rules define a restriction to the state of the system or the change of the system state. Change event rules define automatic actions triggered by a change to the system state. The automatic action can either be a change in data (insert, update, delete) or an action outside the database such as sending e-mail or printing a report. Authorization rules define a restriction on the authorized use of the system. A very good blogpost to implement the Spring Security Plugin is described here: http://blog.springsource.com/2010/08/11/simplified-spring-security-with-grails/

Contraint rules

Constraint rules define a restriction to the state of the system or to allowed changes in the system state. Restrictions to the state of system are known as Invariants. Restrictions to the allowed changes to the system state are known as PreConditions. PreConditions can only be checked when actually performing the change to the data since they are checking whether the change itself is allowed. Invariants can be checked as you perform an action, but can also be checked against existing system objects.

The following subtypes of constraint rules can be identified:

• Attribute
• Instance
• Entity
• Inter Entity

Classifying the rules into the above subcategories is quite simple, since it is very easy to see if the rule involves:

• Only one attribute in one entity object instance (Attribute)
• Two or more attributes in the same instance (Instance)
• More than one instance of the same entity object (Entity)
• More than one instance across multiple entity objects (Inter Entity)

Essentially this subdivision is in increasing order of complexity. When estimating the time it will take to implement a given rule, take into account that Attribute rules are relatively easy to implement, instance rules are more difficult, and so forth.

Lets implement two examples in Grails using custom validators.

Attribute Rules
An Attribute Rule defines which values are allowed for an attribute.

Code example: Date must be in the future

date(validator: {it <= new Date()}) 

Instance Rules
Instance Rules depend on the value of two or more attributes within the same entity
object instance.

Code example: End Date must be after the start date

 static constraints = {
        startDate(nullable: true)
        endDate(nullable: true, validator: { endDate, instance ->
            if (endDate && endDate < instance.startDate) {
                return 'validation.period.endDate.greater.than.startDate'
            }
        })
}

This example appears often in several domain objects an of course is much better to install the constraints plugin, to put this constraint in it’s own class and re-use it in the domain objects. So we don’t have to repeat ourselves and prevent code duplication.

Next time we look at the more difficult constraints Entity- and Inter Entity constraints.