Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Mastering JBoss Drools 6

You're reading from   Mastering JBoss Drools 6 Discover the power of Drools 6 and Business Rules for developing complex scenarios in your applications

Arrow left icon
Product type Paperback
Published in Mar 2016
Publisher Packt
ISBN-13 9781783288625
Length 330 pages
Edition 1st Edition
Languages
Tools
Arrow right icon
Authors (3):
Arrow left icon
Mariano De Maio Mariano De Maio
Author Profile Icon Mariano De Maio
Mariano De Maio
Esteban Aliverti Esteban Aliverti
Author Profile Icon Esteban Aliverti
Esteban Aliverti
Mauricio Salatino Mauricio Salatino
Author Profile Icon Mauricio Salatino
Mauricio Salatino
Arrow right icon
View More author details
Toc

Table of Contents (13) Chapters Close

Preface 1. Rules Declarative Nature 2. Writing and Executing Rules FREE CHAPTER 3. Drools Runtime 4. Improving Our Rule Syntax 5. Understanding KIE Sessions 6. Complex Event Processing 7. Human-Readable Rules 8. Rules' Testing and Troubleshooting 9. Introduction to PHREAK 10. Integrating Rules and Processes 11. Integrating Drools with our Apps Index

When not to use a rule engine

Every project, in one way or another, can benefit from using business rules. They are highly performing, easy to change, and self-explanatory software components. However, there are a group of conditions that a project might have that would make use of business rules a bit of overkill. Some of the characteristics that make a project benefit the least from business rules are shown in the following:

  • There are very few, self-contained rules involved in the project: If the business rules identified in the requirement gathering are very simple and span about one or two objects at most, we don't need a rule engine to run them. A good rule of thumb is that if we can write the business rules that we need as the pseudo code in less than a page and with less than two nested if-then clauses, we might not need a rule engine at this particular time.
  • The business logic doesn't change often: If changing rules at runtime is not going to be needed but the logic is still complex, a rule engine might still be a good idea. However, if the complexity behind the rules is not that high and we can assume it will remain that way for a long time, we might not need a rule engine.
  • A very strict control of the execution flow is crucial for the application: As we stated before, a sequence-flow control is not provided when we execute our business rules. If the business logic behind the business rules depends a lot on a strict set of steps that need to be executed sequentially, business rules might not be the right fit. However, if it does change frequently, perhaps a business process would be worth considering.

It is still a responsibility of the project team to determine whether business rules might be a good fit even if these conditions are met. After all, our experience can lead us to think that the amount of rules has a big chance of growing in the future or there might be situations where the rules will eventually need to change more frequently. Each project has its own unique characteristics and it might be that a project with no need for business rules right now cannot be thought without them in the future.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image