Large Development effort: handling all of these Use Cases, including their change detection, change propagation, and optimization requires 500 lines of code - examine them here.

Remarkably, the actual processing for each of the Use Cases can be easily inferred from a single set of rules. For example, the second rule dictates not only that Add Order should increase the balance, but also that the balance should be reduced by Delete Order or Pay Order.

Transaction Logic: 5 simple declarative rules

By contrast, the windows illustrate the complete logic required to implement Add Order and all the related Use Case;

These parallel the Domain Objects (e.g., stored in parallel packages), later used by the Transaction Logic Engine described below. So, CustomerLogic is the business logic for the Customer domain object.

Logic is specified in Java (or Groovy) classes, using an annotated method for each rule (see transparent blue boxes, below). For example, the CustomerLogic window contains the first 2 rules.

This sample problem illustrates the use and operation of business logic - examine it here.

Referring to the blue callout in the diagram, there are several important aspects worth noting, discussed below.

Automatic Invocation / Re-use - automates multiple Use Cases

Unlike procedural programming where you must explicitly call and order your logic, the rules above are automatically invoked by the Transaction Logic Engine (described below). The engine assumes the responsibility to monitor all of your transactions, re-using the logic whenever dependent data is changed.

5 Rules = 500 lines of Java

The 5 rules entirely represent the logic that would otherwise require 500 lines of Java.

Consequently, the 5 rules above address all of the Use Cases - automatically. This not only saves 500 lines of code, it eliminates an entire class of design errors such as neglecting logic elements of a Use Case.

Such automation is familiar. If you declare a spreadsheet cell as the sum of a column, the spreadsheet "knows" that it should recompute the cell when any column data is altered, or when a row is added or deleted. In ABL, the balance = sum (unpaid ordertotals) rule automatically adjusts the balance for all Use cases that touch the dependent data - Add Order, Delete Order, Pay Order, etc.

Automatic Optimization - avoid geometric reads

In a declarative approach, you specify what you want rather than how to do it. This enables - obligates - the engine to optimize your logic.

The rule balance = sum (unpaid ordertotals) looks very much like a SQL sum. It is not.

Instead, the logic engine's optimizer utilizes adjustment logic, so altering an amountTotal by X simply adds X to the balance. select sum logic for purchaseorders and items is replaced by a single row update.

Automatic Ordering - automates maintenance

Inherent in a declarative approach is that rule chaining is supported (one rule can reference the results of another), and that the system assumes the responsibility for detecting dependencies for correct ordering. So, the derivation rules for balance and ordertotal can be specified in any order.

This is most important during maintenance: in manual code, the principal time is spent in studying the existing code to understand its dependence-based ordering. ABL eliminates this costly (and unpleasant) "archaeology" by deducing dependencies to compute a correct order of operations. So, you need only alter rules to meet the business requirements - dependency management / ordering is automatic.

Plug-in Architecture: no re-coding, fits in

This diagram depicts the use and operation of business logic; note that:

You do not directly invoke business logic or the Transaction Logic Engine

Easy to get started - plug-in means no recoding

No Coding Changes

Since Hibernate/JPA APIs are unaffected, you develop client applications such as the one shown here in exactly the same manner as you are accustomed.

To use business logic, simply configure and add logic classes.

This "plug-in" approach means you don't have to alter your (or your framework's) existing code to utilize business logic. You simply change a configuration file, and introduce logic classes - at your own pace.

Automation often incurs costs of efficiency, or limitations. The Transaction Logic engine is designed for extensibility:

In addition to using annotations to specify logic, your logic methods can use Java or Groovy logic with if/else, loops, etc as required

Such Java/Groovy logic can invoke Java/Groovy methods, so you can build re-usable rule type extensions

ABL includes extensions that illustrate extensibility, and automate classically complex Use Cases such as a Bill of Materials explosion, a deep copy, or the allocation of a Payment to a set of outstanding orders.

Automated Optimizations such as pruning and adjustment help achieve and maintain enterprise class performance

Domain Based: logic is supplied on Domain Objects (not specific services), so that the system can enforce them across all Use Cases

Plug-in: the plug-in architecture makes it easy to get started (no recoding), and fits into your existing runtime / development environments

Strategic Business Advantage

ABL provides strategic business advantage:

Agility: replacing 500 lines of Java code with 5 rules - for 40% of your system - means you can better respond to business change

Quality: automated re-use can reduce the common (and painful) scenario often discovered in final tests, where logic elements are not coded into some Use Cases

Performance: pruning and adjustment optimizations can reduce the common (and painful) scenario where systems ran fine in development for small database sizes, but require major rewrite to deal with production size data.

You can install a fully executable Spring project of the demo shown above as described in the title link. Note: this is ready to run - the domain objects are defined, the controllers are built, and the project is fully configured. The database is embedded so requires no installation.