Docs‎ > ‎Reactive Logic Tutorial‎ > ‎

Extensible Libraries


Allocate Payment to Orders

The patterns above illustrate the most common patterns we see in logic design. The sub-sections below describe the more complicated cases we have seen through extensive experience.

You will see that the solutions are remarkably short. So the coding to deliver complex problems is small. The solutions, on the other hand, are dense. This illustrates the power of logic to address complexity, and also that the real job centers on the design and approach instead of low level coding. Exactly where it should be.

Add Payment - allocate to orders

This is a classic example of the providing an allocation re-usable service via Business Logic Extensibility.  Here we add a Payment to a Customer, and its amount is allocated to that Customers' outstanding unpaid orders. 



Please see the database structure (excerpted above):
  • The allocateFromTo rule creates payment_order_allocation rows that represent the amount of the payment disbursed to each recipient Order.  

  • payment_order_allocation logic determines the exact amount allocated, 

  • Which then increments the orders.amount_paid 

  • Which in turn affects the orders.amount_un_paid, which adjusts the customers.balance.

The full logic (6 rules) is shown here:


 

The full payments event logic (summarized above) is shown here:



You can explore allocation using the Rest Lab, here.


Business Logic Pattern

Study this example carefully - Allocation is a very prevalent pattern.