Context
Implementation of a service operation requires a lot of decisions making and different action to be performed based on them. The implementation code can be difficult to understand and reason out to make any changes to it. In agile we tend to depend on unit tests to understand such code. Unit tests is one level removed from the actual code.
The regular implementation of such code would involve reading data from repository, calling domain objects, making decisions and writing data to the repository. There is lack of pattern in the structure of such code. Other service methods which implement similar kind of logic, for lack of any method structure pattern, would read uniquely to the developer. Often such code are explained on a white board.
Rule object pattern provides consistent structure to such code. A service method which involves rule object breaks up like:
- load all the data by calling the repository into the rule object.
- service method calls the rule object whether a particular action has to be taken or not and performs the action based on that.
- constructs a response object in the end.
Rule object is typically created only for a given service method. The constructor of a rule object demands all the objects it needs to make decisions.
Rule object poses a question which I would leave unanswered here. Would the code be easier to understand if there are patterns in sequence of instructions.