• grue@lemmy.world
    link
    fedilink
    English
    arrow-up
    13
    ·
    edit-2
    22 hours ago

    There’s a certain amount of stuff that’s more or less common to all computer programs: the need to get input from and display output to the user, the need to interact with various features of the hardware (e.g. saving data to disc), etc. A lot of the code in the program is infrastructural boilerplate, transforming and moving around data between those things.

    “Business logic” is everything else – the code implementing the computation that fulfills the program’s purpose, described in terms of the problem domain.

    For example, if you’re “manipulating a string” that’s probably infrastructural code, whereas if you’re “formatting a mailing address” that’s probably business logic.

    The common sorts of apps that exist to automate some straightforward bureaucratic workflows (i.e. filling out forms, but on a computer) are often designed with a “three tier” application architecture. The first tier is the UI, the third tier is the database store, and the middle tier is the business logic doing the calculation and validation that a clerk would’ve done by hand in the previous paper-based process.

    Apps that operate in a more complicated way, such as CAD software, might tend to have a fuzzier distinction between business logic and infrastructural code.