Enterprise software systems are a very interesting case study for Object Oriented Analysis and Design. The domain is reasonably complicated to warrant thinking in terms of objects, plus the enterprise systems tend to evolve over time. Requirements change and the task of maintaining the consistency of the entire system is quite difficult given that usually multiple teams have worked on it. Thus most of the enterprise systems that “I have seen” tend to be Object Oriented.
Enterprise systems tend to be very rule oriented. For example raise an alert if today is m days from an event are very common requirements in a business system. And these rules are very much prone to change. Rules for a desired result can be added or removed with changing requirements. Modelling such rules is a challenge.
The easiest way to express a rule is the if then else statement that most of the programming languages support. This is the easiest step in the process. But finding a natural home or object for the if statement can be quite tricky.
Business objects are never home for rules. It is best to keep the business objects as simple and straightforward as possible and add only such logic that would make sense in all the contexts in which the object is used. Example
class Message {
private final int priority;
public isPrioritized(){
return priority != -1;
}
public shouldRaiseDeliveryStatus(){
return isPrioritized();
}
}
The method isPrioritized deals only with the data from this class, and is derived directly from the representation of priority (the int priority variable). Hence it is a candidate for a member function. Where as the other method shouldRaiseDeliveryStatus is not dependent upon the representation of priority, but upon the behavior of the Message (viz isPrioritized). This means that shouldRaiseDeliveryStatus is not a member of this class, but can be the member of some other class.
Lets not be architectural astronauts here and try to figure out some properties of the class to which the shouldRaiseDeliveryMessage belongs to. For one, the class should obviosly have Message as one of its state members. The question of what others members belong to the new class is a question of context. If the rule behind raising the delivery notification sufficiently complex enough, it warrants a new kind of class which I would like to call the Criteria Pattern.
Criteria Pattern as the name implies models a business rule. When thinking of any new pattern, I always try to analyze how consistent is it with known OO techniques. Criteria pattern forms a part of the stable intermediate form discussed by Grady Booch, also it is a candidate for the ubiquitous language discussed by Eric Evans. As these are the only two major texts that I have read on OOP, this is the limit of my knowledge.
Back to the example, let us say that the business rule of raising of delivery status message changes and requires that a delivery status be raised when a message isPrioritized and also when the system message queue is not full. This requires that whatever class is making the decision, should have a reference to the system queue, and Message class is not a very good place for that. Usually, the code is moved to some service class which checks the criteria and raises the message. This would mean that the service class will have some domain logic embedded which does not bode well for the rich domain put forth by Eric Evans in DDD. A criteria which can be directly traceable back to the domain can be the new home of such a rule.
class RaiseDeliveryStatusCriteria {
private MessageQueue messageQueue;
@Autowired
public RaiseDeliveryStatusCriteria(MessageQueue systemMessageQueue){
this.messageQueue = systemMessageQueue;
}
public boolean shouldRaiseDeliveryStatus(Message message){
return messageQueue.isNotFull() && message.isPrioritized();
}
}
