We all start our new projects by promising to follow best practices and good design principles etc.
But over the time business rules change and developers keep adding new features or updates existing logic.
In this process the common mistake done by many teams is putting if-else conditions here and there instead of coming up with better design to support enhancements. Once these feature turn on/off flags and behavior branching logic started creeping into code then overtime it might become un-maintainable mess. The original developers who design the basic infrastructure might left the organization and the current team left with a huge codebase with if-else/switch conditions all over the code.
So we should be very careful while designing the classes holding the business rules and should be flexible for changes. No matter how much care you take you might still need to touch the code whenever a business rule changes.
This is a problem because we are burying the business logic in the code. Drools framework tries to address this problem by externalizing the business rules which can be authored or updated by non-technical people as also (at least theoretically :-)).
Recently a new book is published by Packt Publishing titled "Drools JBoss Rules 5.X Developer’s Guide".
I was asked to review the book and here it goes.
Chapter 1: Programming declaratively
I would strongly suggest to read this chapter even if you are already familiar with Drools.
Author Michal Bali explained the problems with putting business rules in code and how Drools addresses these problems.
This chapter also has When not to use Drools section which I find very useful to determine whether you really need Drools for your project or is it overkill.
Chapter 2: Writing Basic Rules:
Here you can start getting your hands dirty by familiarizing yourself with Drools syntax and trying out simple examples.
This chapter also introduces various concepts and terminology of Drools, so don't skip this.
Chapter 3: Validating
This chapter covers building a decision service for validating domain model. Any concepts can be explained better with an example rather than lengthy explanations.
Here author did a good job of taking a real world (if not completely real world, but non-trivial) banking domain model and explained how to build the validation rules with several examples.
In this chapter you can find plenty of example code snippets that are commonly used in many of the projects.
Chapter 4: Transforming Data
This chapter covers transforming data from legacy system to new systems and applying various rules in the transformation process.
Author explained how to use IBatis for loading data which I find as outdated topic, now it is MyBatis with cool new features.
Note:
But actually I doubt if any legacy system with huge volumes of data can really use this feature at all because if needs all the data to be loaded in memory.
I prefer Kettle(Pentaho Data Integration) kind of tools for this purpose.
Chapter 5: Creating Human-readable Rules
One of the main promises of Drools is you can configure business rules in human readable format.
Ofcourse developers are also human beings(:-)) but here the meaning is non-technical people also should be able to understand the rules and with little bit of training they should be able to configure new rules or update existing ones. This chapter covers authoring the rules using Domain Specific Language (DSL). Author covered wide variety of rules configuration options using DSL including configuring and uploading rules from CSV or XLS files.
The rest of the chapter go in-depth of Drools covering advanced topics which I haven't yet gone through.
Chapter 6: Working with Stateful Session
Chapter 7: Complex Event Processing
Chapter 8: Defining Processes with jBPM
Chapter 9: Building a Sample Application
Chapter 10: Testing
Chapter 11: Integrating
Chapter 12: Learning about Performance
Appendix A: Setting Up the Development Environment
Appendix B: Creating Custom Operators
Appendix C: Dependencies of Sample Application
So far I feel it is good read and I would strongly suggest to read this book if you are building an application with complex business rules.
No comments:
Post a Comment