This summarizes Automated Business Logic: what, why, how, and for whom.   In particular, it provides an overview of how you can optimize the use of Business Logic over your project life cycle.

See here for a Technical Summary, and here for an Executive Overview.

What is Business Logic?

Business Logic is the processing you execute on save/submit: 

  • Constraints

These are the most obvious elements of business logic - multi-attribute, multi-table expressions that prevent bad data from being committed into the database.  For example, you might want to ensure that the customers' balance does not exceed their credit limit.

  • Derivations

The most challenging element is derivations, since these are typically chained (dependencies require detection and properly ordered change propagation), and multi-table (so performance-sensitive).  For example, you might want to compute the customers' balance by summing their order totals, in turn derived from the Line Item amounts.

  • Actions

Actions include auditing, copying, messaging, business process initiation, etc.  Ideally, these are generic, so they can be re-used over multiple Use Cases and Domain Models.

Such logic should be architected so that it encapsulates domain access, automatically shared over all User Interfaces and Message-based transactions.  In interactive applications, it is the logic that must be executed in with save/submit operations.  In addition to the classic example on the home page (summarized in the following section), you can see several examples in the Tutorial.

Automated Business Logic addresses only save (transaction) processing.  It complements other familiar forms of business logic such as presentation logic (data retrieval / update processing, screen flow), Business Process Flow, or Decision Logic commonly associated with Rete engines.  It complements Enterprise Integration packages for data exchange.

What is Automated Business Logic?

Automated Business Logic is a
"logic engine" that plugs into Hibernate, and executes declarative (spreadsheet-like) logic you supply in companion classes that correspond to your POJOs.  This encapsulates your business logic, while leaving Hibernate interfaces and POJO objects unchanged.  
You gain agility and transparence due to elimination of 90% of your business logic code, since the engine automates the "when/how" of conventional coding.

This sample problem (Customers, Orders and Parts - shipped in the download) is a simple way to illustrate the use and operation of business logic.  The requirement Customer's balance may not exceed their credit limit is addressed as follows:

  • Constraint rules

Far beyond simple single-attribute validations, the requirement is multi-attribute constraints, such as this Customer Constraint:

balance < creditLimit

  • Derivation rules
Constraints are the most familiar form of business logic, but derivations and actions are the most valuable, per dependency / re-use automation noted below.  Derivations here include multi-table derivation rules such as

Customer.balance = sum(order.total where paid = false)

Note that:
  1. Derivations are multi-table, as in the example above

  2. Derivations can chain, both to constraints, and other derivations:

         Order.total = sum(Lineitem.amount)
         Lineitem.amount = quantity * partPrice
         Lineitem.partPrice = copy(Part.price)

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

  4. Derivations can include if/else logic, state transition logic, and reference related data

  • Action Rules - address requirements such as auditing, copying (e.g., an order clone), or invoking a business rules engine
For more information on rules:
  • Core Rules: a quick summary of all the core rules with link to their detail descriptions
  • Extensibility: Click here to see how to extend the Rules
  • Tutorial: uses a Case Study approach to illustrate how rule utilization

Why do I need Automated Business Logic?

  The logic of Business Logic:
  1. Business Logic is 50% of the Build Phase 

  2. Within Business Logic, a key need is multi-table logic (sums, counts, references to related parent data) 

  3. Such needs are poorly addressed by
    • Rete Business Rule Engines that perform poorly, and do not assure integrity
    • Manual code requiring significant code expansion that is neither agile nor transparent 

  4. Business Logic addresses multi-table logic using simple business expressions
    • replacing 10 pages of code with 5 business-oriented rules, providing substantial agility and transparency to Business Users
    • executing with Enterprise-class performance optimizations for SQL elimination/minimization

How does Automated Business Logic affect my project life-cycle?

Business Logic Overview

To use Business Logic:

  1. Build your applications,

  2. And your Domain Objects in the usual manner

  3. Specify your Business Logic declaratively, using your IDE (e.g, Eclipse)
    • Your IDE provides code completion and error indications for building rules
    • And a debugger, for use in Logic Debugging

  4. Hibernate invokes the Business Logic Engine as an event listener.
    • The engine invokes your logic (re-use is automatic)
    • And performs read/write of your Domain Objects using Hibernate data access / transaction APIs

  5. Publish your Logic through automatically generated Logicdoc, with transparent Requirements Traceability to Logic

  6. Use the Console to check data integrity, view logs, etc


The sub-sections below illustrate the use of Business Logic over the life-cycle of your project:

  1. Analysis: uncover Business Logic Requirements by adding rigor to current process
  2. Design: automated by chained formulas - like a spreadsheet
  3. Development: declare 7 rules instead of 10 pages of code
  4. Execution: the Business Logic Engine minimizes/eliminates SQLs
  5. Maintenance: automated re-use, re-ordering and re-optimization - just change the rules


Use your existing methodology to uncover Business Processes and Use Cases.  Automated Business Logic can enhance this process:
Logicdoc: requirements capture
Logicdoc provides a mechanism to capture the Use Case Requirements, with traceability to the Business Logic that implements them.  This information is published through Javadoc (like this), with special services to enable Business Users to read the relevant business-oriented sections (like here).
Alert: excessive design detail
    1. In particular, watch out for extended pseudocode which simply expands on Business Logic automation services.
    2. Be aware that Automated Business Logic services eliminate many key elements of design, such as delineating the individual Use Cases for adjustment.
    3. Extension services (such as allocation) introduce concepts that can significantly increase the level of abstraction in team communications.

Design Automated by Chained Formulas - like a Spreadsheet

Unlike procedural approaches where there are very complex design decisions (re-use, ordering, partitioning, and optimization, etc), Automated Business Logic automates these elements of design. It does so by applying the metaphor of a spreadsheet to business logic, as described in the sub-sections below.

Design Process: familiar step-wise definition of terms

To nail down the understanding of the Check Credit Requirement, an Analyst might
  1. Have the the following conversation with a Business User in the course of elaborating the Check Credit requirement (left column), and then (perhaps afterward)
  2. Specify the Logic that implements the requirement (right column)

Check Credit Design Process - stepwise definition of terms
Analyst / Business User Dialog

Captured in Logicdoc
Resultant Business Logic

Is Executable: replaces 10 pages of code
What does it mean to Check Credit
Balance can't exceed Credit Limit
Constraintcustomer.balance < customer.creditLimit
What is the Credit Limit?
Entered by the Sales Department
(Assure Data Model contains this attribute, and that an Application exposes it to the Sales Department)
What is the Balance?
Sum of the unpaid orders marked "ready" by the user
Sumcustomer.balance = Sum(orders.amountUnPaid where isReady)
What is the AmountUnPaid?
Discounted amount - amount paid
Formulapurchaseorder.amountUnPaid = purchaseorder.amountDiscounted - purchaseorder.amountPaid
What is the discount amount?
Platinum customers get a 5% discount off the total

purchaseorder.amountDiscounted = purchaseorder.amountTotal
if (purchaseorder.customer.creditLevel == "P")

purchaseorder.amountDiscounted = purchaseorder.amountTotal * 0.95
What is the AmountPaid?
Let's defer that until we discuss Make Payment, later in the Order Process
What is the AmountTotal?
The total of all the Lineitem Amounts
Sumpurchaseorder.totalAmount = Sum(lineitems.amount)
What is the Lineitem Amount?
Quantity Ordered * Part's Price
Formulalineitem.amount = lineitem.qtyOrdered * lineitem.partPrice
What if the Price changes after the PO?
Ah, right, customer gets the original price

Formula lineitem.partPrice = ParentCopy("Part.price") // no cascade

We have denoted the rules in the right column. As you can see, Business Logic solution closely matches the detailed statement of the problem: an Executable Design.

Optionally, as further explored in the Place Order Detail Description, you can preserve this analysis discussion in your Logicdoc generated documentation:

Design Preservation with Logicdoc

 Requirements  Implementation


The first key concept of spreadsheets is that you don't write code, you declare formulas. As illustrated in the table below, Automated Business Logic uses the same declarative metaphor, and provides analogous execution automation for ordering and change propagation.

In a Spreadsheet 

In Business Logic
Define cell formulas:
cell A = sum (column B)
Define Domain Object attribute formulas
Customer.balance = Sum(order.amountUnpaid where isReady)
  • Note: to address a database of related tables, these formula are Multi-table.
From this, the spreadsheet "knows" that
adjust A when B elements are inserted, updated and deleted
The Business Logic Engine "knows" to automate the transaction processing
adjust Customer.Balance when Orders are inserted, updated and deleted and updated (reassigned to different customers, paid, etc)

Forward Chaining: automatic multi-table dependency management

Spreadsheets can express enormously complex problems - without programming - because they support what Computer Scientists call Forward Chaining: formulas can depend on each other

So, you alter a cell, and its effects ripple through the spreadsheet. This is not a simple process, since the spreadsheet must determine a dependency-based execution order to get the correct answer.

The same ordering issue exists in Automated Business Logic, but now both within a row and - much more significantly - between rows

The sub-sections below briefly examine the specific cases the Business Logic Engine must address to automate multi-table transactions (observe: all such Forward Chaining in executed in the context of a Hibernate transaction).


Formula Ordering

The Dependency Analyzer of the Business Logic Engine examines every Formula, and orders their execution with respect to their dependencies. This addresses within a row; the following sections address between rows.

Child Aggregate Adjustment

Observe the Customer.Balance rule involves two related parent/child Domain Objects.

As described in Business Logic Execution triggered by Child changes, changes to child attributes are analyzed. If (and only if) any attribute is changed that is part of a declared Sum (a summed attribute, a Foreign Key, any part of the Qualification Condition), the system:

  1. Adjusts the Parent Sum
  2. Forward Chains to execute Parent Business Logic (other Derivations, Constraints, etc)

This process can chain. The example above automates a conventional multi-table transaction involving Customer, Purchaseorder, Lineitem and Product.

Parent Reference Cascade

Make Ready

See the Make Ready example for an excellent illustration of these concepts in action.
The PurchaseOrder.AmountDiscounted rule also involves 2 tables with the Customer.Level parent reference. The Business Rule Engine's Dependency Analyzer detects all Parent References from child Domain Objects.

If (and only if) Parent Referenced attributes are changed, the Business Logic Engine will Forward Chain to each referencing Child instance so that it can re-evaluate its Business Logic in light of the new data. This is called Cascade processing.

Constraints and Actions

The key point is that all derivation changes trigger automatic constraint / action processing.  This is most common logic pattern, and the core of virtually every representative example.  It is also the reason why simple constraints/actions - that do not address multi-table derivation results - fall quite short.

Design Automation

Referring again to the Design Process table above, we emphasize that the right hand column is fully executable.  The system is responsible for all the activities usually meant by design: 

Development: Declare Business Logic

Once your Analysis process has identified the rules, you declare them as follows:

Declaring Business Logic
To declare Business Logic:
  1. Create a Java/Groovy Business Logic Component
    • This is a class that corresponds to a Hibernate-managed Bean (Domain Object)

    • The Logic Engine provides access to current/old values, and Logic Context
    1. Create a method for the Business Logic Rule (identified by Annotations) 

      • Your component can contain other methods 

      • Your Business Logic can reference these and other Java/Groovy services


    The Check Credit example above illustrates how just 7 Business Logic Rules can replace 10 pages of code. Even if you think you can code and debug 1 page per day, the agility of automation is overwhelming.

    Power through Open Declarative Business Logic

    Your Business Logic is fully declarative: the Business Logic Engine is responsible for Ordering, Re-use and Optimization. You can declare your rules in either Java, or Groovy which provides a more natural syntax and automatic type. You acquire power at two levels:

    Declarative Business Logic addresses complex logic
    The Check Credit example is a typical transaction in terms of complexity. The Business Logic Rules scale to truly complex transactions, as shown by the fully worked / described examples in the Tutorial (full implementation is shipped with the product):
    • Computing a Bill of Materials Kit Price, based on the transitive closure of all the components (and sub-components) of the kit 

    • Exploding a Bill of Materials on Place Order, so inventory reflects the remaining stock for the transitive closure of all the components (and sub-components) 

    • Cloning an Order (a deep copy) 

    • Computing a Department Budget, reflecting the transitive closure of all the sub-departments (and sub-sub Departments) budgets 

    • Placing a Payment, allocating to all the outstanding orders, oldest first

    Complexity Management

    The underlying concept is Forward Chaining, a fundamental tool in complexity management. As your local Computer Scientist will tell you,  program size depends on the number of interactions**2. So, automatic dependency management results in a profound reduction of code - arithmetic, not geometric.

    Java Extensibilty

    Most Business Logic specifications are simple spreadsheet-like expressions:

    • price * quantity
    • Sum(orders where isPaid=true)
    • balance < creditLimit

    Beyond such expressions, significant additional power is provided by Open Business Logic: your logic can invoke Java/Groovy methods. You can use existing Java/Groovy methods, or utilize Extensibility. This enables your organization to use/build a library of re-usable logic services such as date functions, or completely new Business Logic Rule Types such as allocation or copy. The latter are shipped with the product, both for your use, and as illustrations of how to build Extensible logic.

    In addition to logic extensibility, the Business Logic Engine is architected for systems extensibility. You can supply your own factories to select the Business Logic Component for a Domain Object (e.g., PurchaseorderRetail vs. PurchaseorderWholesale). Events are provided so you can determine all the changes in a transaction. And, mechanisms are provided to accomodate your Hibernate extensions, such as configuration.

    Automatic Invocation

    You do not directly invoke Business Logic with explicit API calls. Instead, the Business Logic Engine is registered as a Hibernate Event. When invoked, Business Logic Engine locates and executes the Business Logic Rules you define in Business Logic Components that correspond to each Domain Object.

    Assured Integrity
    Unlike Rete Business Rule Engines which require explicit invocation, this means that integrity is assured. Elective integrity simply cannot guarantee integrity if it depends on a programmatic call.

    Simplified Adoption

    Automation invocation also means Business Logic easy to adopt: you can introduce Automated Business Logic with minimal impact on the rest of your system (even if portions have already been coded).  As shown in the BusLogicDemo, you need not recode existing logic such as JSP - you simply

    1. Introduce your Logic classes

    2. Add a line to your Hibernate Config file

    In addition, the engine provides services to eliminate migration of existing logic, so you can use Automated Business Logic for new logic, even in systems which previously used procedural business logic.

    Automatic Partitioning promotes re-use and performance

    It is sadly true that far too much procedural business logic winds up in client event handlers. This can interfere with re-use between screens, and makes the logic unavailable for message processing. It can also lead to performance issues, since network traffic can be increased by not centralizing the logic in the server.

    Unlike manual approaches, Business Logic guarantees that the logic is partitioned for re-use and performance.

    Execution architected for high performance

    The Business Logic Engine is architected to Minimize/Eliminate SQL overhead.

    • Pruning: the Business Logic Engine analyzes updates, and avoids parent access, adjustment and cascade when the referenced data is not changed 

    • Adjustment Logic: maintains aggregates with a single SQL
      Unlike Rete Business Rule Engines that load all the data into memory, or issue aggregate Select sum queries, this assures optimal performance. This is particularly important with there are chained aggregates

    Maintenance Automation

    Maintenance is a process that is reduces business agility, is expensive, and hated by developers.  Declarative Business Logic can automate large portions of maintenance as described in the sub-sections below.

    Automatic Re-use

    Re-use is a core development objective, requiring substantial design effort in procedural approaches to maintain critical database integrity.  It is certainly not automatic.  And it is critical for Compliance Assurance.

    Business Logic, however, operates as an Event Handler, so active enforcement of business rules and re-use is automatic.  This re-use occurs at the level of both code and design, as described below.

    Code Re-use - over transaction source

    Object oriented languages provide this re-use, by requiring all accessing code to use an objects' method.  Hibernate events enable an analogous level of encapsulation with events.

    Automated Business Logic employs these to assure that all Hibernate-based updates are subjected to the Business Logic you specify.  Such automatic invocation guarantees integrity regardless of transaction sources (customers get the same answer regardless of the interaction):

    • Interactive business logic is not required in page actions (controllers), avoiding the anti-pattern of business logic in page actions which cannot be used for message-based transactions

    • Message-based - services automatically re-use the domain logic, so that services are thin

    Design Re-use - over transaction type

    Even more powerful - and much less common - is encapsulation of not just code, but design intent.  This arises since your logic is declarative: you declare what the effect should be, not how (the methods that implement it).  The power of this is best illustrated by a deceptively simple example.

    The Customer.Balance rule, perhaps declared for Place Order, simply states that its value is the sum of the unpaid orders.  It does not tie this to an algorithm, enabling the system to optimize with efficient approaches such as adjustment.  Nor is the rule tied to a particular method (Use Case) - it's design intent applies to all transaction types.

    This design intent is declaratively encapsulated into the Order Domain Object, so that it is automatically re-used over all these related transactions:

    1. Delete Order - the balance is reduced
    2. Pay Order - the balance is reduced
    3. Reassign Order to a new customer - new customer balance increased, old balance decreased (for unpaid Orders)
    4. All the various cases of Change Order:
      1. Change a Line Item Quantity
      2. Change a Line Item Part
      3. Add a Line Item
      4. Delete a Line Item

    So, when you make a maintenance change to your logic, the system automatically reflects it in all the relevant transactions.  This emergent behavior means you define rules for 1 transaction, but solve many transactions you might even have overlooked.

    Automatic Re-ordering

    The core element of maintenance is the archeology to determine how the current code was ordered, so that new code can be merged without error. Business Logic eliminates this requirement, since the ordering is executed automatically the the Business Rule Engine.

    Automatic Re-optimization

    Unlike traditional systems whose performance degrades with each patch due to time constraints, the Business Logic Engine always applies the performance considerations noted above. On every change.  So just like SQL query optimizers confer the benefits of database improvements to all retrievals, Automated Business Logic provides continuous optimization of transaction processing.

    In this way, Business Logic provides many of the same benefits that were introduced by relational database. Before it was available, programmers hard-coded index access strategies into their code. When subsequent use revealed the need for an index, it was typically impractical to recode all the programs.

    Business Logic provides the same benefits for transaction processing that relational database did for data retrieval. For example, imagine a hand-coded system where the decision to make a sum transient was based on a slight miscommunication. That presumption might be build into a multitude of services.

    It might not be until near the end of the project during load testing that the assumption was revealed to be false. The development team is faced with the unpleasant aspect of finding/re-coding all the locations where transience was presumed.

    With Business Logic, you simply change the specification. The system will automatically revise transaction processing strategies from SQL to adjustment, just as a program based on relational data need not be recoded as indices are added/dropped. This applies the concept of data independence to transaction processing.


    Agility comes from a number of sources:

    • Build Phase: the code reduction from Complexity Management results in a several orders of magnitude reduction. This is often about half of the build phase of a project (the other half being screen development).

    • Iteration / Maintenance: here the effect is not so much code reduction as design reduction. Every time you alter the rules, the system recomputes the execution order, the re-use tactics (assuring the rules are called for all relevant transactions), and optimization strategies. These take time, and in some cases ignored (e.g., performance often degrades over time due to the cost of re-optimization).


    Automated Business Logic provides transparency in a number of dimensions:

    • Design
      Logicdoc (illustrated above) enables you to capture your Requirements in Business User terms, and track the actual implementation into executable Logic. Business Users become partners in the development effort, making your Business Logic a true corporate asset.
    • Execution
      Logic Debugging provides a full Console of logic execution, with the option to use your IDE's debugger.
    • Administration
      Logic Console enables you to manage a deployed application: understand which logic is running, monitor its performance, etc.

    Who uses Business Logic?

    Business Logic can represent a corporate asset since it forms a language understandable to many groups within the organization:

    • Developers: use Business Logic to displace Java code they currently must otherwise implement, so they are the main users.
      • Application Developers specify the actual rules 
      • Systems Developers and Architects leverage the Extensibility services to extend the Rule Types, and integrate Business Logic into their architecture

    • Business Users: as illustrated below, the Business Logic Rules provide transparency to the organization, particularly when present in the context of PURL 

    • Managers: can also quickly inspect the implementation in ways that are impractical with code 

    • Business Analysts: can use Business Logic to document the Requirements in such a way as to facilitate the ensuing implementation

    Business Logic as a Corporate Asset

    Automated Business Logic can become a true Corporate Asset:

    1. Automation confers Business Agility, in building and revising systems of high quality - a strategic business advantage
    2. Transparency represents a common language between Business and IT - congruence in business needs and IT systems

    When: Next Steps

    If you think Business Logic holds promise for your organization,