liveapicreator-admin-cli

<h2>Business Context</h2> Story: Place Order.   Task/Requirement: Check Credit.  (or, your methodology / terminology).   <h2>Business view</h2> When placing an order, check credit - elaborated as follows (the <cite>"cocktail napkin spec"</cite>)...  <ul> <li>the Balance must be less than or equal to the Credit Limit, where...  (step-wise definition of terms)</li> <li>the Balance is the sum of the unpaid Order Amount Totals, where...</li> <li>the Amount Total is the sum of the LineItem Amounts, where...</li> <li>the Amount is the discounted Price * Quantity, where...</li> <li>the Price is obtained from the Product</li> </ul> A good spec - clear, concise.   <hr /> <h2>Conventional Design</h2> In a conventional approach, you might design the following pseudocode: <ol> <li>Compute the LineItem.amount <ol> <li>Read the Product to get the Price</li> <li>Multiply by qty_ordered to compute the amount</li> </ol> </li> <li>Update the PurchaseOrder.amount_total <ol> <li>Read the PurchaseOrder</li> <li>Increase the amount_total</li> <li>Update the PurchaseOrder (to cache)</li> </ol> </li> <li>Update the Customer.balance <ol> <li>Read the Customer,</li> <li>Increase the balance</li> <li>Update the Customer (to cache)</li> </ol> </li> <li>Check that balance <= credit_limit <ol> <li>Throw exception with error message for UI handling</li> <li>Rollback the transaction</li> </ol> </li> </ol> But Place Order is just one Story.  We need analogous logic for all the related Stories (Detete Order, Pay Order, etc etc).   <hr /> <h2>Reactive Rule Approach</h2> And that's the power of declarative reactive logic.  You simply state the rules below (nearly the same as the cocktail napkin).   <h2>Reactive Rule Execution: Watch, React and Chain</h2> And (as in a spreadsheet), the rules are automatically applied to all incoming transactions: <ol> <li>They watch for changes in data referenced by rules</li> <li>They react to changes in referenced data.  Execution order is dictated by dependencies.  </li> <li>They chain - including across tables.  So changes to line items affect their order, which affect their customer</li> </ol> Note it works across tables.  Consider the customer balance - the sum of the unpaid order amounts. It works rather like a spreadsheet.  Order changes are watched, and the balance is <ul> <li>increased when order inserted</li> <li>decreased when order deleted... or paid</li> <li>adjusted when the order amount total is changed... or assigned to a new customer... or the line items are altered</li> </ul> Observe persistence is automated (no need to read/write the customer, or deal with transactions).  And it's optimized: <ul> <li>adjustments are 1 row updates, not select sum queries</li> <li>sql is averted if the watched data is not changed</li> <li>caching is provided (inserting multiple line items results in just 1 adjustment to order and customer)</li> </ul>   <hr /> <h2>Bottom Line</h2> That means the following Stories are automatically addressed with our 5 "cocktail napkin" rules: <ul> <li>Delete Order - the balance is reduced</li> <li>Pay Order - the balance is reduced</li> <li>UnPay the Order - balance is increased</li> <li>Reassign Order to a new customer - new customer balance increased, old balance decreased (for unpaid Orders)</li> <li>Reassign a Line Item to a different Product - adjusts the order's amount total</li> <li>Add a Line Item</li> <li>Delete a Line Item</li> <li>Change Line Item Quantity</li> <li>Reassign Product to Line Item</li> <li>Do multiple of these, in combination ("no, 2 hammers, not 1 shovel")</li> </ul> A conventional approach would require hundreds of lines of code, might easily miss corner cases, and be tedious to maintain.