Sometimes people call certain parts of software "business logic" or mention "business programming", especially when it's related to web services. Afaik, ALL software that is sold with the intention to make profit, is business. What does the term business in business logic, business programming, etc... in software, mean, and what makes certain code "business" and other code not? Thanks for the clarification :)

It usually means the code specific to the particular app/domain, such as calculating discounts in a shop, as opposed to generic code (like file and db access) which doesn't really care about what the app is actually built for.

Think of it as the "gameplay" code of the real world.

Think of it like the "business" end of a shotgun. Its the stuff that gets shit done.

If it requires domain knowledge outside of computer science, it's considered "business". Example: Mortgage code that calculates fees.

Quote: Original post by necreia
If it requires domain knowledge outside of computer science, it's considered "business". Example: Mortgage code that calculates fees.

How about code that detects if a molecule can cause cancer? It's also knowledge outside of computer science...

Over here B-Com (Or business and computing), is simply software engineering related to the creation and maintenance of business applications. By business applications, I mean financial databases and reporting tools, content management systems for business websites, and stock management modules. Basically anything which helps a business maintain it's stock and finances, or provides a business with an electonic window to their consumers (Such as a website). It may sound limited, but then the scope of finance and stock maintenance systems can be overwhelming.

For example, I have to know how every module of my employer's ERP system works, right down to the complex general ledger module which binds it all--Most of the time, I just cheat and look at how the software works rather than the business process behind it. On the other hand, the employees who maintain each module only have to specialize in the module allocated to their department--And even then they still manage to screw it up.

It's specialized area of "Software Development". And I use the term "Software Development" pretty loosely, not to downplay the merit of Business Developers (I am one after all) but because it's more related to Information Technology than Computer Science. The bulk of the work is database design and management, with a software layer to provide a user friendly GUI to query and maintain said database.

its impossible to talk about "business logic" without talking about a multi-tier architecture. The most common form of this being a three-tier system.

1) Data
This is the raw data that is required for your application to run. Data is viewed as inert or neutral and is stored independent of the logic or presentation.

2) Logic
When a request is made from the presentation layer, data is requested from the data layer. In the logic layer the data is massaged or turned into information that is useful to the end-user and is then passed back to the presentation layer.

3) Presentation
This layer determines how that information gets displayed to the end-user. This layer also is responsible for receiving input from the end-user and passing it on top the logic layer for appropriate validation and processing.

What people call "business logic" or "business programming" refers to Layer 2, the logic section. The majority of the actual "work" is done in the logic layer.

So yes, the code to detect if a molecule can cause cancer would be business logic. The data that it makes that inference from would be in layer 1 and how it displays that information to the user would be in layer 3. But the core work is done in the "business logic" layer. This form of architecture can be applied to any form of application.

Quote: Original post by Lode

Quote: Original post by necreia
If it requires domain knowledge outside of computer science, it's considered "business". Example: Mortgage code that calculates fees.

How about code that detects if a molecule can cause cancer? It's also knowledge outside of computer science...

Yeah, that'd come under "business" logic. "Business" logic is really a misnomer from a programming/software engineering point of view. A better name would be domain logic as it pertains to the (non-software) rules of the given application. These rules are typically modelling some already defined system, which can be a physical process, accounting procedure, game element or business rule.

Quote: Original post by Lode
Sometimes people call certain parts of software "business logic" or mention "business programming", especially when it's related to web services.

Afaik, ALL software that is sold with the intention to make profit, is business.

What does the term business in business logic, business programming, etc... in software, mean, and what makes certain code "business" and other code not?

Thanks for the clarification :)

In the system I'm building now, we accept applications to colleges. There's an exception handling framework, there's a data access layer, there's user management, and finally there's the bits of code that perform calculations relating specifically to the act of accepting college applications, as in whether to approve or deny them based on their standardized testing results, stated major intentions, etc.

In this example, we only consider the last part to be "business logic". Pretty much everything else is boilerplate functionality that can very easily be adapted to other business uses, and frequently is.


At my last place of employ, we had 5 separate banking applications which managed completely different aspects of mortgage lending. Probably around 70-80% of the code for all 5 apps were shared, the remaining 20-30% being specific to the Line of Business (LoB). In this case, that 20-30% would be considered business logic.

Quote: Original post by kryat
its impossible to talk about "business logic" without talking about a multi-tier architecture. The most common form of this being a three-tier system.

1) Data
This is the raw data that is required for your application to run. Data is viewed as inert or neutral and is stored independent of the logic or presentation.

2) Logic
When a request is made from the presentation layer, data is requested from the data layer. In the logic layer the data is massaged or turned into information that is useful to the end-user and is then passed back to the presentation layer.

3) Presentation
This layer determines how that information gets displayed to the end-user. This layer also is responsible for receiving input from the end-user and passing it on top the logic layer for appropriate validation and processing.

What people call "business logic" or "business programming" refers to Layer 2, the logic section. The majority of the actual "work" is done in the logic layer.

So yes, the code to detect if a molecule can cause cancer would be business logic. The data that it makes that inference from would be in layer 1 and how it displays that information to the user would be in layer 3. But the core work is done in the "business logic" layer. This form of architecture can be applied to any form of application.

^This

Essentially, any business rules discovered during the Customer/Business requirements analysis phase of your project that requires an IT enforcement/activity shall be enforced/validated/activated within the "Business Logic" layer. The major goal of this decoupling is for scalability and flexibility. Any modifications to the solution does not mean we need to duplicate business rules, we simply re-use the "Business Logic" layer. Conversly, should the Business Rules change, we have a single point of modification.

Although this can be applied to most small to medium sized business applications, the lines become blurred depending on what design pattern you use. Also note that on Enterprise level solutions, you may have an entire application/component (or multiples) that act as your "Business Logic" layer. Generally this layer is the intermediate layer between your data bases/data warehouses and your frontend applications. Often bridged together via interfaces such as Oracle Fusion or webMethods, or workflow management systems such as ControlM.