Transactional Business Logic is important - often half the app for update oriented applications. And there are issues that directly affect business agility and TCO:
- Time: logic is built manually, without automation tools such as UI frameworks. So, the 5 simple requirements shown here result in 500 lines of code. Rete-based Business Rule Engines don't provide active enforcement of logic, and deal poorly with aggregates (sums and counts).
We believe it should be as fast and easy to deliver applications as it is to imagine them (picture the venerable cocktail napkin shown below). ABL is designed to provide competitive advantages in agility, TCO and transparency, operating as follows:
- Complexity: debates persist - Anemic Domain Objects? Services Layers? Logic-enhanced Domain Objects? Data Access Objects?
- Familiar annotations declare multi-table logic, somewhat like spreadsheet formulas. Annotations are powerful (each representing 100+ lines of code), yet so simple they are transparent to both IT and Business Users. Annotations address over 95% of your logic, and you can use Logic Methods to address more complex requirements.
- The ABL Logic Engine plugs into Hibernate events - since you don't directly call the logic, you do not need to recode your application, and integrity / re-use is assured. The engine automates multi-table execution order based on dependencies, so that development cycles and maintenance simple entail simply changing the logic, without the tedious archaeology to decipher existing code.
Logic Annotations declare multi-table logic
ABL enables you to dIrectly enter the requirements as shown below. While you might uncover this logic to govern a specific Use Case (e.g., entering an order), it is automatically re-used over all transactions.
Logic Engine plugs into Hibernate/JPA Events
One typical approach is to build a service layer for multi-table transaction logic. This approach makes it unnecessary in most cases, since the logic-enhanced Domain Objects enforce the multi-table business logic. You can, of course, retain a services layer, but the services will be thin since they re-use the logic of the underlying Domain Objects.
We characterize the result as a Rich Active Declarative Domain Model:
- Rich means that the domain objects enforce multi-table constraint and derivation logic (eg, rollups), as well as actions such as auditing, deep copies (eg, clone an order), and starting business processes.
- Active means the rules are automatically enforced on any update. Encapsulation / re-use is automated using event injection.
- Declarative means that dependencies / ordering managed automatically, draining enormous amounts of code out of your logic.
Perhaps you are skeptical, but hopefully intrigued. We've prepared an Evaluation Guide. Ask questions here, we will try to respond. Our website is designed to assist you in exploring this concept, and includes downloads and examples.