The problem solving technique is all about policy and the formula for calculating dynamically for software products

Tram Ho

These days, I have a very accidental relationship with software in the banking and finance sectors. Some problems in this area remind me of my early days working with Trinet Expense software. I have developed a technique for creating the configuration of policy to check cost reports.

In today’s scope I will introduce a similar problem I encountered when working with a new financial software product of mine.

Problem:

You build a survey and affiliate module for a finance company to collect user information. The fields in the survey will be dynamically designed using the example survey libraries below:

For each survey we will have different bonus formulas dynamically configured in the database so that when the collaborator refers clients they are calculated commissions according to the company’s rules. Here are 2 recipes to apply with the “Apply as a credit card” survey:

  • If the number of documents the collaborator introduces as a credit card in the month> 5, the commission for the collaborator: 300k, F2 (Father level) = 50k, F1 (Grandparents level) = 50k
  • If the number of documents the collaborator introduces as a credit card in the month <5, the commission for the collaborator: 200k, F2 (Father level) = 30k, F1 (Grandparents level) = 20k This leads to us I have to configure some bonus formula like this:

This problem is identical to what I did with Trinet Expense when I needed to dynamically configure policies for cost reports.

Analyze an inducement. It looks like we have some rules like below

  • Rule Status of record
  • Rule Number of records for the month completed
  • Advanced rules if they want to check a certain field in the results. Imagine we need to do something that can represent this kind of formula.

if (ruleA-> and (ruleB) -> or (ruleC)) then

  • Charge for collaborators
  • How to calculate the fee for the collaborator’s father and grandpa levels to save this in the DB, we simply use a table with the following schema:
  • Field if_clause
  • Field formula

Okay, Done with schemla and how to save to DB

Now comes the arduous part of the scholarship concerning how to use something supernatural like the Design Pattern and OOP to represent all these formulas in the programming language. See the following Diagram class, the so-called beautiful Hiep zai Pattern:

Source code github: https://github.com/ericbui148/hieppattern

Share the news now

Source : Viblo