Duplicated formula in front and back end

Question

I'm struggling with logic that is duplicated in the front end code and the database. Right now, I just put a comment.

Here is a small example (the current system has a lot of much more complicated formulas).

In the front end, I have a single property that everything use to see the result.

Class CartItem

    ' The same formula is found in the database view V_CART_ITEM
    Public Readonly Property Cost As Decimal
        Get
            Return Price * Amount
        End Get
    End Property

End Class

In the database, I have a view that all queries and report use.

CREATE OR REPLACE VIEW V_CART_ITEM AS
-- The cost formula is also found in the class CartItem
select cart_item_id, price * amount as cost
from cart_item;

I think it's not to bad since the formula is only duplicated once in the whole system and a new developer would know what to do if there are any changes to be made. I'm wondering if there's a better way.

Answer 1

It would be better to only have this logic in the object.

You should protect your database with an API layer and have all queries/reports go through the API.

In the API layer you can use your object, thus ensuring that the Cost field will always be populated correctly

Answer 2

Always have one definition for your business rules.

That is a good rule, in practice though things get muddier. Particularly if you have multiple front-ends that do not agree on any form of shared implementation, or any shared implementation would be to brittle/slow/complicated to use. Even if you do manage to get all of the business rules into a shared medium, you still have the problem of keeping each of the applications/databases/etc... using the same logic - despite our sincerest efforts deployments are not instantaneous.

So how do you get around that? Tests and Versioning

Ironically you can write tests that check the UI/API/Database/Extracts/Reports and use the same Logic to check that the result appears to have been calculated by the same rules. To improve maters take a two prong approach:

• pick specific values and predetermine their output values. Use the input values to test both the Test Logic, and the Application Logic. This establishes a minimal baseline.
• randomly fuzz inputs using the logic in the test engine to determine the expectation, and compare that against the reality - report inconsistencies. This explores the unknown space and lets you determine where the Test and Application Logic diverge. The Fix is a decision as to who is right, consider taking those values and casting them as a specific test.

Secondly because there will likely be a time when parts of the system are out of sync as to what constitutes Business Rules, tag the protocols and objects in use with a version. At the very least do not operate on objects which do not match the version of the logic. If your code is smarter it might up-cast the object to the new version, or alternately fall-back to the older logic.

Answer 3

The complicated formulas constitute business logic. It depends from team to team on where they keep their business logic. A team with developers fluent in backend, would prefer to store business logic in SQL while a proficient full-stack team would be more comfortable with business logic in the API.

I prefer to keep straightforward business logic in the API like most developers reserving SQL SP's and Views for very complicated business logic to make use of database optimizations.