Business Logic

Though often used, the term business logic is vaguely defined.  

We use it to mean transactional business logic - multi-table computations, validations and actions -- see here.
Hibernate/JPA has become the standard for database access, by automating read/write using annotation mapping declarations.  Now you can use the same annotation-based approach for your Transactional Business Logic (see thumbnail).  This is important due to:
  • Time and cost: save/submit logic is often 50% of the development effort for update-oriented applications, which directly affects business agility and application TCO

  • Complexity: what is the basic approach - a services layer? add logic to domain objects?

ABL enables you to declare Logic Annotations
, executed when you commit hibernate transactions.  This provides significant business advantages:
  • Agility
     - the 5 logic Logic Annotations at right (click to view) replace 500 lines of traditional Java code, since they automate dependency management and change propagation over all Use Cases (the bulk of the code using a traditional approach).  Our experience is that over 95% of your logic can be automated in this manner.
  • TCO - optimizations/ordering are repeated on each change, reducing iteration / maintenance costs. Compliance verification is dramatically simpler, since you need to verify just the logic, not all the calling code.

  • Transparence - logic can be read by Business Users, who can help identify errors/omissions to reduce requirements risk

Big claims - we know.  Here is how ABL works:

1.  You 
declare business logic in Logic Annotations - just as you do for Hibernate - including:
  • Derivations
In particular multi-table derivations such as

Customer.balance = sum( where paid = false)

Power: 95% Coverage, 100X abstraction

Reflection may suggest this demo is a very typical transaction.  

Our experience is that logic automation addresses well over 95% of the logic required for complex systems, consistently representing 100 lines of code per logic declaration.  

The training provides some complex examples to help you explore this.
Note that:
  1. Derivations are multi-table, as in the example above

  2. Derivations can chain to other derivations:

  = sum(Lineitem.amount)

           Lineitem.amount = quantity * partPrice

           Lineitem.partPrice = copy(Part.price)

  3. Chaining and dependencies are automatically handled (logic is declarative, somewhat like a spreadsheet)

  4. Derivations can include if/else logic, state transition logic, and reference related data
  • Actions - address requirements such as auditing, copying (e.g., an order clone), or invoking a decision rules engine

  • Logic Methods - you can supply more complex logic in Java/Groovy logic methods.  These can invoke other Java/Groovy code, enabling you to extend the logic engine to automate recurrent logic patterns.

  • Constraints - far beyond simple single-attribute validations, support is provided for multi-attribute constraints, such as this Customer Constraint:

balance < creditLimit

2.  A Logic Engine listens for Hibernate events. At commit time (no code generation), it locates the logic (if any) for each updated row, and executes the logic in a correct and efficient order...
  • Correct means that logic dependencies are determined (using byte code analysis), so changes to dependent data are propagated in a correct order - including across tables

  • Efficient means such propagation is pruned and optimized where dependent data is not altered. This is particularly important for multi-table logic such as sums/counts, to avoid unnecessary SQL overhead

This results in a a Rich Active Declarative Data Model architecture, providing a number of advantages

  • Excellent Architectural Separation
Domain objects are unaffected, and existing Hibernate APIs are unchanged. This plug and play makes business logic easy to try, with existing code, and frameworks that automate Hibernate calls, such as these.
  • Active automated enforcement

Logic is encapsulated with Domain objects, so re-use is automated over all related Use Cases. So, the logic above, while perhaps conceived for add order, is automatically applied to delete order, update order etc

  • Architectural automation
Architects can be assured the logic is re-used and optimized, unlike manual approaches which can introduce coding / architectural errors

Service Layer, often motivated by multi-table logic complexity, is optional for most cases. If desired (e.g., publish APIs for SOA access), services can be thin since they invoke the logic encapsulated into the Rich Domain Objects.

Decision Logic

Decision Rules remain appropriate for Business User rule management, e.g., Decision Tables, and for cases not related to persisting transactions.
Transaction Logic complements Rete-based Decision Rule Engines with a direct focus on transaction-oriented logic:
  • Optimized Aggregates - Hibernate integration means that the system can prune updates requiring no changes (eg, changing order date does not affect customer balance), and when updates are required, the system can use adjustment logic to avoid well-known Rete geometric read issues

  • Automates active enforcement - no explicit calls to invoke the logic engine are required, since the engine listens to Hibernate commit events arising from existing Hibernate APIs

  • Transition Logic - integration with Hibernate means logic expressions can reference old values (eg, Employee.salary > Employee_old.salary)

Now take the Tour, and download a free copy for evaluation.  To download the ZK demo with installation / configuration notes, click here.