Automated Business Logic Layer for ZK with Hibernate/JPA

asked 2011-08-29 15:48:59 +0800

ValHuber
24

Frameworks continue to evolve, simplifying application construction:
   *ZK does a great job of simplifying Rich Internet Applications
   *Hibernate/JPA provide valuable services to make data models available within the MVC paradigm.

Business Logic, however, remains a bit a mystery - problem, since this is often 50% of the development effort for update-oriented applications.

I have observed a number of fundamentally different approaches for implementing business logic. Some advocate a services layer, others advocate adding logic to domain objects. I have not yet read anything entirely convincing. Though the term is often used, there is considerable confusion, ranging from definition to architecture to proper tool utilization.

Having pondered this for a while now, I have collected some thoughts in this paper. It’s an approach that accepts a Service Layer as an anti-pattern, and proposes event injection of declarative logic into Domain Objects - a Rich Active Declarative Data Model.

While the concept can be applied to multiple architectures, our company has implemented what we believe is a preferred implementation, namely:

1. Specify business logic in "logic classes" that parallel your domain objects. Logic includes

   a. Derivation rules, in particular multi-table derivation rules such as
               Customer.balance = sum(order.amount where paid = false)
      Note that:
         * Derivations are multi-table, as in the example above
         * Derivations can chain, eg,
               Order.total = sum(Lineitem.amount)
               Lineitem.amount = quantity * partPrice
               Lineitem.partPrice = Copy(Part.price)
         * Chaining and dependencies are automatically handled

   b. Constraint Rules - in particular multi-attribute constraints, such as
               customer.balance < company.creditLimit

   c. Action Rules - address requirements such as auditing,
      or invoking a business rules engine such as Drools or BPM

2. A Logic Engine plugs into Hibernate events. At commit time (no code generation), it locates Logic Classes (if any) for each update, and executes the logic in a correct and efficient order...

    a. Correct means that the logic dependencies are determined (using byte code analysis), so changes to dependent data are propagated in a correct order including across tables

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

This architecture has a number of advantages

   1- Excellent Architectural Separation

      a. Domain objects are unaffected

      b. Existing Hibernate APIs are unchanged.
         In particular, automation is retained for frameworks that automate Hibernate calls.
         This has been verified with ZK and Grails/Gorm (often used for zk persistence)

   2- Automated Active Enforcement,
      Logic is encapsulated with Domain objects, so re-use is automated over all related Use Cases.
      So, the rules below, while perhaps conceived for add order,
      are automatically applied to delete order, update order etc:
         Customer Constraint: balance < creditLimit
         Customer.balance = sum (order.total where paid = false)
         Order.total = sum (Lineitem.amount)
         Lineitem.amount = quantity * partPrice
         Lineitem.partPrice = copy(Part.price)

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

It complements Rete-based Business Rule Engines (BREs)

   * Automates active enforcement - no explicit calls to invoke the logic engine are required

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

   * 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 SQL aggregate queries or reading all related objects into memory

   * BREs remains appropriate for Business User rule management, e.g., Decision Tables, and for cases not related to persisting transactions

Business advantages

   * Agility - the 5 rules noted above replace over 100 lines of traditional Java code since they automate dependency management and re-use over all related Use Cases (add order, delete order, update order, reassign order, etc) [deleted rules since repetitive]

   * Transparence - the rules can be read by Business Users, who can identify errors/omissions to reduce requirements risk

   * TCO - optimizations/ordering are repeated on each change, reducing maintenance costs. Compliance verification is dramatically simpler, since you need to verify just the logic, not all the calling code.

   * Architectural automation - architects can be assured the logic is re-used and optimized, with a significant simplification over manual approaches which involve many non-trivial design choices

I am interested in feedback and reactions.