Business Logic Definition

Business logic is that portion of an enterprise system which determines how data is:

Business logic should be distinguished from presentation logic and business rules:

Presentation logic is that portion of an enterprise system which determines how data will be displayed or reported.

Business rules are formal expressions of business policy, e.g., "all invoices since 2013 will be charged a Value Added Tax of 20.0% on VAT-applicable goods," or "negative dollar amounts shall always be shown in red on financial documents." As such, business rules can determine both business logic and presentation logic.

It may help to consider a simple but illustrative example like computer chess: The game itself, i.e., the board and the pieces, their movements, and how the rules of the game are handled independent of any display or user interaction is business logic. Business logic is often exposed -- and only exposed -- as an API. Presentation logic determines how the board and pieces are displayed, and translates user interaction (e.g., mouse clicks and the like) into moves. Presentation logic interacts with business logic via the business logic API.

The chess scenario doesn't help the tricky scenarios so far. For example, a given report can be viewed as a grid of cells, much like a chess-board, and the "logic" may determine which cell has which value. But some seem to consider that "presentation logic", perhaps because there are many ways to display the same info, and a particular report is just one of many (one of many sorts or groupings or column combo's).

A "given report" is presentation logic, by definition.

Please elaborate, especially in terms of how its different from chess logic. I see no significant conceptual difference.

It isn't. Your misunderstanding of presentation logic vs business logic appears to apply equally to both. Do not confuse the presentation of the chessboard with its internal representation. In other words, a "grid of cells" is how the data is presented, so it's presentation logic. How the data is generated and manipulated may have nothing to do with a "grid of cells" -- it might be in a linked list. A "grid of cells" is how the chessboard is presented, so it's presentation logic. How the data is generated and manipulated may have nothing to do with a "grid of cells" -- it might be in a linked list. Etc.

We could implement the report via linked lists also. It's just not deemed the best model in most cases.

That's irrelevant; I mention it only as an example of the distinction between how something is displayed (presentation logic) vs how it is generated and manipulated (business logic).

Then find a better example. I see no significant or useful conceptual difference between chess computations and report cell computations.

ClassificationIsTough. It's best to focus on practical maintenance patterns rather than get bogged down with classification-mania. You are over-thinking it and making a mess in the process.

The industry seems to have no problem with these distinctions, and my students and colleagues grasp them readily and intuitively. If you don't understand, I suspect I can't help you. The "mess" is your own to deal with.

Your difficulty in turning such notions into clear-cut rules suggests the problem is on your side. With enough examples, people can "fit" things into the "proper" categories via the typical features of neural-net-based technologies, such as fitting/predicting/mirroring the teacher's notions. But that's not good enough for definition; that's merely pattern matching based on a sample set. I've done that successfully many times to score better on exams, but its not proper/complete reductionism of concepts. One expects things like, "A chess computation has property foo while report cell computation lacks property foo, and property foo is a necessary requirement per rule 7" or whatnot. That's not asking too much.

It's been turned into definitions and an example at the top of this page. Your difficulty in turning such clear-cut rules into notions suggests the problem is on your side.

They are defined on vague words. We have gone round and round on "determines" for example, without clarity forming. If you think your def is clear, then we'll just have to part ways and LetTheReaderDecide. I see vagueness and flip-flopping.

You may need to spend more time working on developing enterprise systems, in a variety of areas -- not just reporting -- before these things become clear.

So then I'll "just feel" what is what? Even "Enterprise software" (EnterpriseApplication) is vague. How fitting. Often it's a buzzword for those who want to puff up their resume.

Whatever it is, your response is more evidence that you work outside of it. When you've worked on -- and been responsible for -- all of the first twelve bullet points under EnterpriseApplication, I can guarantee (yes, guarantee) you'll appreciate the distinction between business logic and presentation logic.

That's a non-answer, and doesn't help the definition along even if it was true.

That may be the case, but given myself and others have tried multiple times to explain what is seemingly obvious to us -- and obvious to much of the industry, it seems -- I can only suggest that more experience may be needed in order to appreciate the context.

If it was "obvious" you'd be able form a clear-cut definition. You've taken no formal survey so we can't verify it's consistent across persons. And I entered the industry when mini-computers were the primary business computing tool, and saw the tail end of punched cards. You don't know who you are talking about.

I've been around since before VAXen and have used punch cards. I've worked and been responsible for every aspect of EnterpriseApplication development. I've managed IT departments and accounting departments. I've been an IT consultant to everything from one-man businesses to multi-national corporations. You don't know what you are talking about. I have thirty years of industry experience. You have one year of experience thirty times. I rock. You suck. <insert pissing contest here>

So you are a reincarnated zombie? Cool!

Yeah. That. </sarcasm>

Anyhow If separation is not useful for small and medium-sized applications, but only "big expensive" projects, that's useful information. Would you agree to that?

Separation is always useful. For small projects and only small projects -- e.g., those written in an afternoon and used for a week before being deleted -- it is perhaps not economical to do anything but bang out bad code as quickly as possible.

As I've mentioned somewhere below, I agree separation is useful, but not necessarily on biz-versus-presenation. Our current code is generally 2D such that we only have one primary category we can separate on. If we waste it on one, then we don't have it for another splitting category. I'm just trying to spend complexity wisely. -t

I suspect that might work well for developing data entry and reporting applications, i.e., working entirely in the presentation logic domain.

Everything is "data entry and reporting". A video game gets "data entry" from the joy stick and "reports" the state of the model on the screen. That's not a useful phrase.

The phrase "data entry and reporting" invariably refers to business data entry and reporting. Google for the phrase.

The definition of "business" has fuzzy edges. Anyhow, the phrase implies zero processing beyond canned report features, which is false. Apps I work on usually have a lot of domain-specific business logic. It's a continuous line between "small" biz apps and BigIron/expensive biz apps. I see no useful hard boundary.

My only distinction between big and small apps was that some small apps might be sufficiently urgent and disposable to not be worth any effort to make them good, i.e., bang them out as quickly as possible. Could you provide an example of the sort of domain-specific business logic you work on?

That's also continuous. BusinessLogicDefinitionDiscussion asks the same question about examples.

It does indeed, and I think answers would be helpful.

"[A]ll invoices since 2013 will be charged a Value Added Tax of 20.0% on VAT-applicable goods"

How is that conceptually different than "all invoices since 2013 will be marked with footnote #7 on report X"?

A tax total exists whether it's presented or not. "Footnote" and "report" are, by definition, presentation. Neither are calculated, retrieved or stored.

Routing packages or bills is really different from routing photons? I don't see the logic or practicality in discriminating against photons. Or consider a rule that says "disclaimer X shall be displayed on all bills containing Y". If that ain't biz logic, then I am a monkey's uncle.

Photons are irrelevant at this level, much as wood cells are irrelevant at the level of house architecture.

3rd scenario: you have a menu with 7 items, but 3 of them are to only be shown to "administrative" users and hidden to regular users.

"Menu" and "shown to" clearly indicate presentation logic. Neither are calculated, retrieved or stored.

What do you mean by "calculated"? Do you mean a numeric value? In this case it's controlled by a Boolean calculation, which shouldn't get less rank than numbers. And I thought you suggested elsewhere it's not about "storage". The rule scenarios above would typically be a business decision, not a "presentation" (artist/graphic designer) decision.

It's not about storage, but use of storage as a data source can be evidence of data manipulation, which is business logic. Business decisions are supported by or implemented by business logic. "Presentation (artist/graphic designer) decisions" are presentation logic, by definition.

Evidence? That's still not very specific.

[Definitions aren't theories. They don't need evidence. The value of a definition is judged by other criteria (utility, acceptance).]

You introduced the word here.

And why not? It's being used in its generally-accepted manner.

"Generally Accepted" is not measurable and not documented. There is no committee that determines such; and as you should realize by now, different WikiZens have different views of what is "typical" or "normal" for the industry(s) such that relying on those being stable or accepted for definitive statements is asking far too much.

We can identify "generally accepted" on this Wiki as being that with which everyone agrees, except you.

Pfffft. your handle-less wiki buddy, you, and a dog named Boo versus me. Oh wow, thoroughness abounds.

I see very little conceptual or organizational reason to consider A and B very different "kinds" of "things": 

  // A:
  if (complex_decision_calculation()==true) {
     display_thingy();
  }
  // B:
  if (complex_decision_calculation()==true) {
     route_package_to_foo();
  }
Again, routing photons versus routing packages is merely a media difference. It's old-fashioned to consider them different where physical and bits or electrons are classified and thought of differently. -t

Whilst there may be a philosophical similarity between emitting photons and calculating tax, from a pragmatic point of view it makes sense to distinguish presentation logic from business logic. They are treated as distinct because the distinction has a direct impact on systems architecture and design. Business logic is wholly independent of display mechanisms, so it does not need to consider user interface issues -- thus, an entire area of design complexity need not be considered. Likewise, presentation logic does not need to consider calculation and data routing, but it does need to consider user interfaces and user devices -- such as mobile vs desktop, or browser vs custom client, or all of these at once. As a result, business logic tends to run on servers -- in DBMSs and application servers. Presentation logic tends to run on clients -- in browsers and mobile and desktop devices.

I'm sorry, I still find that nebulous. "Wholly independent" is an extreme criteria. Some interdependency is common and likely and could easily change such that it shouldn't be a pivot-able characteristic.

[You seem to be mixing display/presentation with your business logic, but that doesn't mean they're the same. And while 'business logic' may be somewhat vague (as many definitions are, including 'business'), it's still practical.]

At certain times and places.

"Business rule" and "business logic" are typically used interchangeably. Does anyone propose they mean different things in practice? Business rule is usually used to refer a specific feature, request, or activity; while business logic is usually used to refer to sets of business rules or the general concept. But, this is only a tendency and not a solid rule (no pun intended).

Business rule and business logic are only used interchangeably by those who do not know the difference. I've rarely seen them confused. Business rules are statements of business policy. Business logic is code that executes the aspect of business rules that calculates, transforms and routes data. Presentation logic is code that executes the aspect of business rules that displays data to observers.

You are presenting false rigor. There is no force enforcing or declaring a central definition. At least not one that anybody pays attention to.

I'm not presenting "rigor". It's a definition, not a proof. It's a definition based on typical use, not occasional mis-use.

If it's defined by "typical use", then "by those who do not know the difference" is irrelevant. Definitions are usually defined by usage, even stupid usage, as "quantum leap" demonstrates. And I observe "typical use" of differently. We'll have to AgreeToDisagree on how it's actually used in practice.

Working Definition 2

I consider the "presentation" to be issues that are not primarily decided for domain reasons. Which "cells" of a report have asterisks or footnote markers is most likely determined by domain issues, for example, and are thus tied to "business logic". The fonts and colors of a report are not. If a presented element can be changed without hurting or changing domain meaning, then it's probably only "presentation". -t

How does that differ from "presentation logic is that portion of an enterprise system which determines how data will be displayed or reported"? Your "which 'cells' of a report have asterisks or footnote markers is most likely determined by domain issues" is another way of saying that presentation logic is determined by business rules. In other words, as I wrote above, "presentation logic is code that executes the aspect of business rules that displays data to observers."

A computation that determines if a given cell gets an asterisk is BOTH business logic and presentation logic. Your description appears to exclude anything remotely related to presentation.

A "cell" in a report is presentation. A report is presentation, because a report doesn't transform or route data. It displays it to observers. Therefore it is presentation logic, based on a business rule to "show <x> with asterisks on report <r> if <y> occurs."

Again, it's routing photons. To make a distinction is old-world thinking and limiting and arbitrary.

No, it's a reasonable way of partitioning development. Blending presentation logic and business logic complicates development and maintenance, because distinct concerns are tangled unnecessarily. It's like embedding style directives in HTML.

You haven't demonstrated/explained in any usable detail why it overall "complicates development". Anyhow, this topic is primarily about definitions, not partitioning practices. Let's not rekindle that fight here.

It complicates development because you're forced to simultaneously consider two intertwined concerns, when you could more easily deal with each individually.

I have not seen any research that suggests "eye and keyboard movement steps" cost anything, nor have I seen any evidence to suggest the existence of your hypothetical maintenance-heavy MirrorModel.

As for definitions, the ones I've presented accord with convention. See, for example, http://en.wikipedia.org/wiki/Presentation_logic and http://en.wikipedia.org/wiki/Business_logic and http://en.wikipedia.org/wiki/File:Overview_of_a_three-tier_application_vectorVersion.svg

I don't see a clear contradiction with my working definition. Note that "get list of all sales made last year" is shown in the "logic layer". That's for presentation, no?

Providing a facility to obtain a collection of data for what is potentially a variety of purposes, such as "get list of all sales made last year", is not presentation. It may be used by presentation, it may be used by other business logic.

Exactly! Both concepts are slutty mutts.

Huh? "Get list..." is business logic. "Display list" is presentation logic.

So "get list of cells to mark with an asterisk" is NOT?

[You don't "get [a] list of cells to mark with an asterisk". You get a list of items that are important in some way, as determined by a business rule. You then display that list of items, marking the important ones with an asterisk. There's a clear distinction between the two. -DavidMcLean?]

Indeed. Top, "get list" doesn't mean "create and display a drop-down combobox", it means "put data in a data structure".

So if the program puts the asterisks in a data structure first, and THEN displays it, then the asterisk logic is now classified as "business logic", but not if it's direct?''

If the generation of asterisks is only for presentation, then it's presentation logic. If the asterisks drives further business logic -- e.g., "if the customer name's last character is an asterisk, he/she will be charged VIP rates, instead of regular rates, on all SuperStar(TM) rated products" -- then it's business logic. (Never mind that embedding one attribute [customer status] in another [customer name] is, of course, very poor practice.) 

    // Example "flewg"
    // January segment:
    if (<conditionX>) {
       send_postCard_to_customer(...);
       mark_asterisk_on_report7(...);
    }
    // Febuary segment:
    if (<conditionX>) {
       send_postCard_to_customer(...);
    }
    // March segment:
    if (<conditionX>) {
       mark_asterisk_on_report7(...);
    }
    // The conditionX computation is otherwise identical for all 3
I don't believe you thought out your definition very well, and are instead using "notion logic"....with holes.

I'm using conventional definitions. See, for example, http://en.wikipedia.org/wiki/Presentation_logic and http://en.wikipedia.org/wiki/Business_logic and http://en.wikipedia.org/wiki/File:Overview_of_a_three-tier_application_vectorVersion.svg

They are vague or contradicting.

You are inaccurate. To make your statement accurate, it should be, "To me, they are vague or contradicting."

Where explicitly does it exclude the possibility of a given piece of logic being both?

Both what? Both vague or contradicting? Or both business logic and presentation logic? By convention, if the result of logic <x> is used in further processing and presentation it is considered business logic.

So you agree a given piece of code can potentially be both presentation logic and business logic?

No, though in rare cases where they touch -- a statistically-computed vehicle paint colour in a table of vehicles used to display a vehicle-coloured swatch on screen, for example -- it is business logic because the same logic would be needed even if the swatch wasn't displayed.

Arrrrg. Back to example "flewg" above. How would you classify each "<conditionX>" for each of the 3 months (snapshots in time) and why?

It's all business logic, though a procedure called "mark_asterisk_on_report7(...)" is a poor choice of name. Its semantics are more likely "determine_if_customer_needs_to_renew_subscription(...)" or some such -- which is clearly business logic -- and inside Report 7 would be presentation logic like "if customer.is_needing_to_renew_subscription() then writeln('*')"

Design and naming choices aside (diff topic), the intro states "Presentation logic is that portion of an enterprise system which determines how data will be displayed or reported." Using that statement, during Jan. and March, Condition X is "presentation logic". Am I reading that wrong? (Whether that excludes it from other "kinds" of logic categories is yet another issue.)

I have assumed all three conditional blocks are performing calculations or routing, and that the actual generation of reports and postcards -- which is presentation logic -- is elsewhere.

The words "determines" or "impacts" or "affects" is often used, suggesting a liberal interpretation. And your usage of "actual" is not clear enough. I don't know how to objectively determine actual-ness. English may be the wrong tool for the job here.

By "actual", in this case, I mean the code that produces reports or postcards as opposed to code that doesn't. If the boundary is unclear in the code, then the code is poorly written.

Ambiguity exists. You seem to be mistaking your world view as the "standard" way to classify things. But your head hasn't been certified or vetted as the standard, and is poorly documented.

"Produces" is vague. The steps and stages are many. If you have an objective algorithm to determine produces-ness, I invite you to document as an algorithm or a formula. "I know it when I see it" won't cut it.

Also note that sometimes it's best to make a determination early in the process and other times later in the process. Efficiency, resource allocation, timeliness, concurrency issues, etc. all affect at what stage some determination is made, such as what gets included or marked on a report.

Modern programming environments generally allow definition of procedures and methods. Typically, there will be a procedure or method (or sometimes a context, in the case of interactive sessions) that produces a report or postcard. Not having such a procedure or method (or context) -- when reports and postcards clearly need to be generated, otherwise they can't be seen by the user -- is an indication that the code is poorly written.

Perhaps, but this topic is not really about good system design or coding practices. I wanted to settle on a clear definition before further discussing issues related to "good design", otherwise we are stuck arguing with fuzzy language and terms (in another topic not about definitions).

If it's about display or report -- e.g., font, colour, format, layout, advisory or warning message, highlight -- it's presentation logic. If it's manipulation of business data to produce or move business data, it's business logic.

Sure, but those are not the areas of dispute or confusion, such as domain-driven considerations that determine what is included on a report; or the wording of menu items and form field titles. -t

If it's code to determine what is included on a report, or the wording of menu items and form field titles, that is presentation logic. It's still about display or report. 

    // Example: "Discount 44"
    if (<conditionX>) {
       give_customer_a_discount(...);
       mark_asterisk_on_report7(...);
    }
So in this example, Condition X is BOTH business logic and presentation logic, correct???

No, give_customer_a_discount(...) is business logic, and mark_asterisk_on_report7(...) is probably mis-named business logic. As noted above, its semantics are more likely "determine_if_customer_needs_to_renew_subscription(...)" or some such -- which is clearly business logic -- and inside Report 7 would be presentation logic like "if customer.is_needing_to_renew_subscription() then writeln('*')". However, in this: 

    // Highly questionable code
    give_customer_a_discount(...);
    show_report7(...);
...give_customer_a_discount(...) is business logic whilst show_report7(...) is presentation logic. The following conditional code block: 
    // Highly questionable code
    if (<conditionZ>) {
       give_customer_a_discount(...);
       show_report7(...);
    }
...is business logic that invokes presentation logic. That is perfectly acceptable in principle -- one can invoke the other, but that does not mean the code that does so is both at once -- but binding business logic and presentation logic in this manner is generally considered poor practice. If we need to print the report more than once, we'll re-compute the discount needlessly (or perhaps erroneously.) Conversely, if we only need to recompute the discount we'll wind up showing the report needlessly. It makes code maintenance more difficult, too. On the other hand, if (say) show_report7(...) immediately prints some receipt as soon as a discount is given -- perhaps as part of a point-of-sale system -- then it might be reasonable. In that case, it is business logic that invokes or triggers presentation logic.

Mixing in definitions with your idea of "best way to code" is not helpful for settling the definition issue. You are simply re-arranging or labeling things to force the distinction to be clear.

No, the distinction is clear. And we focus on the clear distinction because it helps us write good code.

In practice one often has to live with bad existing designs and/or the reason for display choices is not clear or in flux and it's not practical or politically prudent to obtain such info. It's similar to the "intent" ambiguities described in OverhaulingStyleSheets. In practice there will be ambiguity of intent or purpose or future direction. (And from a design perspective, hard-partitioning on ambiguity risks maintenance headaches.)

Indeed, we do live with ambiguous specifications and business rules and we must make decisions as best we can. The existence of ambiguity, however, is no reason to reject notions that help us achieve SeparationOfConcerns.

In practice we can make fairly clear statements about what the system actually does because that's our primary job and we have to know to do our job right. Classifying the domain (reliably) is not our primary business. It would be really nice to have enough info to classify the domain properly (including reading the requester's mind), but that's IwantaPony because much of the time we won't have that info. (That's why I lean toward designing/partitioning around actual or likely change patterns, not some guessed taxonomy.)

I will entertain the possibility that I work in fucked up organizations while you work for rational stable people and see different problems. But we still need rules/advice for working in fucked up environments because they exist and need IT work done. Let God punish the idiots, for I have a job to do instead.

Indeed. One of the rules/advice for working in "fucked up environments", or any environment, is to strive for SeparationOfConcerns. This is an established best practice, recognised throughout the industry.

The industry is obligated to document clearly the empirical reasons behind a given practice compared with alternatives besides "sounds good on paper". We've had enough stupid fads that fuck up designs, like the OOP hierarchical taxonomy fad or the expert system fad or the anti-factoring MirrorModel MVC and ORM fads, the CASE fad, etc. It's supposed to be the age of science, not the dark ages where the church tells you what to think.

It may be your opinion that "stupid fads ... fuck up designs", except there are a lot of us -- and this is indubitable -- who successfully use OOP hierarchies, MVC, ORM, and CASE tools. None of them are perfect, of course -- nothing is, and there is no SilverBullet -- but they're often an improvement over what precedes them, or they effectively address a particular category of problems.

They work in some cases/situations, but the fad eras usually over-sell their scope and don't bother to research and document their benefits and drawbacks in terms of the alternatives.

It may seem that way, if you listen to salespeople. Don't listen to salespeople.

That's why I seek empirical evidence and representative samples/scenarios. However, many suckers fall for the buzzword bingo show and it generates a fad.

Perhaps. Or, maybe you're missing out on something good. Just because it's a fad doesn't mean it's all bad. People: "Have cake! Cake is tasty!" Top: "I'm not going to taste it -- it's a fad."

If I live to 200 years, maybe I'll have time to thoroughly try and test them all.

[Does RealInformation ever come into the picture or is BusinessLogic only concerned with data? The definition at the top of the page starts with 'Business logic is that portion of an enterprise system which determines how data is:'. It mentions data specifically. Is this intentional or can information also somehow be included in the definition? Presentation logic usually adds context to the data being displayed and is therefore a common form of AdHocInformation?. If information is generated inside the middle tier and is not displayed, this would be part of the BusinessLogic. So information can be part of either section. Then what do you call it if you suddenly decide to show the middle tier information just as it is, in the UI with a RepresentationalUserInterface? Would that be business logic or presentation logic?] --JonGrover

Everybody classifies stuff differently in their head. Thus, rather than partition/organize based heavily on perceived classification, I tend to focus on likely maintenance scenarios and SimulationOfTheFuture. DesignByClassification? is mostly a smell. -t

It's pretty clear by now that the concept or classification of "business logic" is vague, especially in relation to "presentation logic". Needs some work, guys. -t

No, it's really clear that you are not understanding the distinction between business logic and presentation logic.

You are right! I don't know whether it's me or it's you. I try to probe by asking questions and giving scenarios, but get contradictory answers. You just define vague words/phrases with yet more vague words/phrases. You are patching fuzz with fog. "I know it when I see it" is not good documentation. I read your statements 3 or more times and it's vague each time through.

We find it clear. Indeed, the industry finds it clear to the point that it defines architecture around the distinctions.

It appears to be cheating: if you save the results of a calculation in a database, then you call that calculation "business logic". But that's rather arbitrary. We may choose not the save it to a database but rather email it directly one day. The calculations are still there just as before, it's just that now different things are done with the result. I can define Zlob as anything that goes to device A, Hiffnag anything that goes to device B, etc. But that's not a very useful distinction for general design.

Summary of Problems with Designing Around (Hard-Partitioning With) What's Done with Results:

1. What a given result is used for could easily change over time. We don't want to have to re-group our logic when results are used for multiple or diff purposes over time. Shuffling code back and forth costs time and money and risks introducing bugs.

2. Modular construction and task division generally dictate the module only solve the problem the module is designed for and that it shouldn't care what happens to the results outside the module. In other words, the module's internal structure should not be guided by external uses of the module (outside of the spec). Whether the output of a module assigned to me to build is used for printing postcards or firing slackers is not my concern as the module builder and I shouldn't design the module around such guesses. (In practice, it helps to know to fill in the fuzzy areas of the "requirements", which are often fuzzy in the real world.)

--top

Here, I'm taking the introduction and highlighting via brackets all the vague or relative (asterisk) words and phrases: -t

Business logic is that [portion*] of an [[enterprise] [system*]] which [determines] [how] [data] is:

Business logic should be distinguished from presentation logic and business rules:

Presentation logic is that [portion*] of an [[enterprise] [system*]] which [determines] [how] [data] will be displayed or [reported*].

Business rules are formal [expressions] of [business policy]...

AprilThirteen

EditText of this page (last edited May 25, 2013) or FindPage with title or text search