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

* Transformed and/or calculated.  For example, business logic determines how a tax total is calculated from invoice line items.
* Routed to people or software systems, aka workflow.
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.''

* It's the domain that intertwines them, not the designer. You are artificially de-interwining something that is inherently intertwined. Maybe doing such helps YOU think about stuff (MentalIndexability), but I am not you, and neither are %99.9999999 of the world population (give or take a few decimal points). Without WetWare studies, it's hard to empirically analyze such. Further, separation is a matter of degree. Separation via function is "weaker" separation than separation via file, for example. It's not all or nothing. And you are ignoring the extra maintenance costs of the MirrorModel hoppity-hop dance and bloated shared areas. These cost more eye and keyboard movement steps. Indirection is rarely free, especially 1-to-1 indirection.

* ''The domain doesn't intertwine them.  Presentation logic is always distinct from business logic.  It's as simple and distinct as the difference between processing and output in a system consisting of input->processing->output.  It's as simple and distinct as the difference between "a := b + 4" vs "writeln a".  '''You''' are intertwining separate strands.''

* Output is relative. One processes' output may be another's input. Making an iron-wall distinction between paper and a file or database is '''media bigotry'''. One thing that made Unix/Linux successful is '''uniformity in input and output treatment''', making no hard-wired distinction between input and output destinations or media type. "Print" is just a shorthand for "stuff -> printerDevice" which is not really different than "stuff -> a".

* ''In the context of a given system, output is only output.  That it might be input to another system (or your eyes) is immaterial.''

* I think we are going to go LaynesLaw over "output". It's a relative concept.

* ''Output isn't relative in this context.  It's what is emitted by a system, i.e., it leaves the system.''

* System? If I "print" to a PDF or HTML file, it's not physically leaving the system. Plus, it's often useful to view "system" in a fractal sense in that each function/object/module/app is its own mini-system to feeds to and from other mini-systems. Hard-partitioning based on a certain level size creates both conceptual and actual reuse problems.

* ''I presume the PDF or HTML will be read by someone?  It needs to leave the system for that to happen.''

* Some HTML pages are generated merely for indexing systems to scan. (It may not always be ethical, but that's another issue.) My point is there is very little reason to make a hard-wired partition between machine and people as the target. For example, if people complain they want to customize the look-and-feel of a report, then you stop giving them a formatted report and instead generate CSV and let them or their batch processes grab and re-shuffle it as needed. This is a fairly common change (or at least generate both a report and a data file). We shouldn't have to rearrange all our code just because we switched it to send to machines instead of printers. '''Transformation for usage by another process is a common activity.''' For example, a given API expects inputs in a certain way and we have to make a little conversion interface or activities to give the API the info in the format/way it wants. Those of us who write a lot of "glue" code spend a lot of time doing just that: converting between sub-systems that "want" data in different ways. It's not conceptually really different than adapting info for human usage: it's just another sub-system that wants things a certain way. I see very little utility in making a blunt distinction between machine users and human users, other than the fact that the latter usually requires more effort to satisfy. It's the same thing, just more of it. -t 

* ''The "someone" can be an external system.  A handy way to distinguish business logic and presentation logic is to note that presentation logic is essentially about formatting.  Business logic is essentially about calculations on business data and state changes.''

** "Formatting" matters to systems also. For example, a given device may want info row-wise when we currently have it column-wise. Thus we have to "flip it" for the other process. It's not human, but it still wants information "formatted" a certain way. Same with adapting our info into API's: the API's want things given to it in a certain way: it cannot just magically transform the current representation we have on it's own. It has to be "reformatted" for the API.  Again, to make a distinction between humans and other systems is rather arbitrary and probably inflexible.

** ''Whether for humans or systems, formatting is presentation logic.''

** Then it's a rather fine-grained distinction and almost no production software I've seen hard-partitions such.

** ''It certainly tends to be separated from core business logic, often located in an interface layer just under the API to the core business logic.''

* But there's no reason to hard-wire a distinction between and internal and external system either. It's just more of a pain to prepare for external systems (human or machines). Effort is an arbitrary thing to partition by. And again, the distinction between "adapting" and "formatting" is fuzzy and continuous, as already described. You seemed to ignore that point.

* I should point out that in custom biz apps I see, very little "calculation" actually happens. Most of the logic is about routing and "switches", toggling features and presentation on/off, etc. and filtering transfers between sub-systems (including "output"). It's a lot of conditionals and very little numeric math.

* ''As I've suggested before, I suspect what you call "custom biz apps" is primarily data entry and reporting.  Perhaps you don't appreciate the division between business logic and presentation logic because the division has already been done for you.  It sounds like you deal almost exclusively with presentation logic.''

* I think we've had this argument like 3 times already. I'll see if I can find one of them rather than reinvent a 4th. Anyhow, it's not about "appreciating", it's about seeing practical the utility in it. I don't see it as a slam-dunk benefit in many orgs. ItDepends on the org and their staffing and maintenance patterns. Sometimes hard splits are warranted and sometimes not. I've done both approaches. It's a practical matter of "will X solve more problems than it causes". I run a SimulationOfTheFuture for '''both scenarios''' in my head or on paper to make that assessment. It's almost that simple. If you want to convince me I'm "doing it wrong", either convince me my simulations are wrong or that SimulationOfTheFuture stinks (compared to the alternatives).

* ''I didn't say you're doing it wrong.  It appears you don't do it at all, because it's apparently been done for you.  You wrote "it's a lot of conditionals and very little numeric math".  Sounds like typical presentation logic of the reporting variety.''

* Sounds like discrimination against Boolean logic. Values are more valuable? (pun semi-intended)

* ''Of course not, but the context in which you're using "Boolean logic" suggests reporting applications.  Indeed, you've never offered any evidence to contradict that assessment, other than variations on "I disagree."''

* Your def of "reporting" seems to be any algorithm not on this list: http://en.wikipedia.org/wiki/List_of_algorithms . That's a rather odd working definition. Maybe if you give a working name I'd feel more comfortable using it, such as "Fred's definition of Reporting" or the like.

* ''Your description of what you do doesn't seem to include any recognised algorithms, or indeed any algorithms at all.  Feel free to prove otherwise by describing, in pseudo-code, an algorithm that you have implemented.''

* Please provide a working definition of "algorithm".

* ''"...A step-by-step procedure for calculations" (http://en.wikipedia.org/wiki/Algorithm).  Above, you wrote "very little 'calculation' actually happens."''

* Boolean algorithms can be done step-by-step. There's a reason I put 'calculation' parenthesis. Much of the vocab of computing comes from the days when most operations were continuous math, or physics-related computations to be more specific. As time went on, more "computing" became discrete math. Discrete math is not lower-ranking in any way.

* ''Indeed, algorithms '''are''' "step-by-step".  Characteristic of algorithms, however, is that they describe a systematic way to solve not just one problem -- or else it's a "procedure" -- but a '''category''' of problems.  The A* algorithm, for example, solves a category of pathfinding problems.  Kruskal's Algorithm solves a different category of pathfinding algorithms.  And so on.  Have you implemented algorithms?  Or procedures?''

* Your terminology is suspect. I think you are talking about "cataloged" algorithms versus non-cataloged algorithms. "If a customer orders more than $300 worth in a year and has bought at least 3 items from List X, then they get a coupon for 10% of their yearly total" is an "algorithm" in every since of the word (or implemented via one). It's just not categorized in the "computer science" sense like A* is. It's a domain-specific algorithm. That does NOT make it "reporting".

* ''What you describe is not an algorithm.  It's a domain-specific procedure.  It does not solve a general category of problems.''

* I disagree with your word usage here. An "algorithm" does not have to be pre-classified or generic to be an algorithm.

* ''An algorithm is an abstraction of a process, not a specific process that has no relevant abstraction.''

* Bullshit

* ''What an amazingly perspicacious argument!  Disguised as an explosive expletive epithet, each letter is actually an image file in which your counter-argument is encoded using subtly-different shades of grey, so close to black as to be invisible to the naked eye.  Next time, however, I suggest submitting your argument in plain English text -- rather than a steganographic tour-de-force -- so that my counter-argument can form an easily-readable counterpoint to yours, otherwise I fear most readers won't be intelligent enough to decode it and will simply assume you're an inarticulate idiot.''

* You are making up definitions out of the blue. How am I supposed to respond to fake definitions? I shall use your suggestion as the template for responding to made-up definitions next time.

* ''I am using "algorithm" precisely how it is always used.''

* Only among your narrow circle of friends.

* ''Sure, if by "narrow circle of friends" you mean "the computer industry".''

* You are delusional.

* ''No, my use of "algorithm" is correct and reflects usage throughout the industry.  How often do your colleagues say something like, "I need the algorithm to calculate this discount?"''

* That's asking to clarify the steps/recipe, not find a larger class of things to stuff it into.

* ''Sorry, not following you.''

* You imply "algorithm" is a general category/class and "domain-specific procedure" is an instance of such a class and thus is not an "algorithm". Where are you getting this definition exactly? I've never seen "algorithm" being about hierarchical taxonomies before.

* [An algorithm isn't a general category, and domain-specific procedures aren't distinguished from them by being instances of that category. Your correspondent in fact implies that an algorithm is characterised by its ability to solve a general category of ''problems'', as previously noted: AstarSearch is an algorithm that solves a general category of path-finding problems, and it may be applied whenever any such path-finding problem arises. A domain-specific procedure, being domain-specific, does not solve a general category of problems. Indeed, a domain-specific procedure will usually solve only exactly one problem. "If a customer orders more than $300 worth in a year and has bought at least 3 items from List X, then they get a coupon for 10% of their yearly total" solves only the problem of "should a customer with the following sales records receive a coupon?", not a general category of problems. -DavidMcLean]

* {I've been searching the literature I have to see if I could find any support for "solves a general category of problems" being part of the definition of "algorithm". I wasn't able to find any. This doesn't surprise me since the term comes to computer science via mathematics; a mathematician isn't going to care whether or not an algorithm solves any problems and adding that restriction would mess up the algebraic structure of algorithm composition. Could you point me to a computer science definition that does include it?}

* ''At home, I have a (rather old) and well-thumbed dictionary of computing that, as I recall, uses almost that exact phrase.  Unfortunately, I don't have it in front of me here at work.  However, the abstract nature of algorithms can be clearly deduced from almost every use of the term, and reduced to a simplistic (and somewhat contrived) example:  We would be unlikely to describe "£435 * 0.20" as an algorithm, or even an algorithm for calculating UK VAT tax on a given total.  We might describe "if (tax_rate && total>0) tax = total * tax_rate" as an algorithm for calculating tax, and it certainly would be.  In the context of this debate, I'm sure Top has implemented plenty of the latter form of algorithm, and if I made it seem like I thought he hasn't, then I take it back.  However, the latter is clearly not what we usually mean when we use the term "algorithm", and whilst the debate has unfortunately centred around the definition of the term, it '''should''' have focused on the original point.''

** I think we can all agree as a working definition/condition that an "algorithm" must have at least some "variables" or "parameters". But that's not a difference maker in this particular discussion. -t

* ''My original point (which I shall augment here) is that Top appears to be arguing against SeparationOfConcerns -- and against clear separation of business logic and presentation logic -- from the point of view of someone who is develops a very particular breed of application.  From what he describes, his development focus is almost entirely on presentation logic, to the point that he probably rarely sees the business logic -- at least not of the usual ApplicationServer and StoredProcedure variety.  Top carries a big presentation logic hammer, so to him everything looks like a presentation logic nail.  Therefore, it's not surprising that he deprecates SeparationOfConcerns -- it undoubtedly appears to be pointless complication.  That's because he probably works on essentially one layer of a multi-layered, well-separated, fully-employing-SeparationOfConcerns, enterprise software stack.''

* It's not of much use to characterize my design recommendations for "separation" if we cannot agree on how to describe what to separate. Statements such as "his development focus is almost entirely on presentation logic" is hard to verify unless we have a solid definition, which is apparently hard to come by. If the concept is fuzzy, which I believe it is, then that's yet another argument for being wary of unconditional separation design rules. Like I said before, we are paid to produce results for end users, not classify the universe. If classification has utility, I have no problem with relying it for design. But if it's fuzzy and/or produces no demonstratable economic benefit, then consider chucking it. Perhaps some of you are "classiholics", having an inborn urge or personality defect to classify everything, whether warranted or not. -t


''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]

* There are different ways to skin a cat. Let's not get bogged down in the "proper" way to include footnotes here.

* ''What does that have to do with what DavidMcLean wrote?''

* Perhaps I misunderstood it. It appears to be promoting a ''specific'' implementation approach when in fact there are may different ways to do it, and this is (was?) not a topic about how best to implement something. It thus has no purpose that I see. What does "the two" modify?

* ''"The two" refers to:''
** ''#1 "You get a list of items that are important in some way..." (business logic).''
** ''#2 "You then display that list of items..." (presentation logic).''

* It may simplify the design to do it all in one step, depending on circumstances. Why have 2 loops when you can have one? Or why have an intermediate structure if you can skip having any structure by just "outputting" it when needed? ItDepends whether it improves the overall design or not.

* ''It may "simplify" the design for some naive definition of "simplicity", but it inevitably complicates maintenance and re-use, and in large projects will significantly increase the perception of complexity and hence the likelihood of error.  Failure to separate concerns is a source of error.''

** That's why we use SimulationOfTheFuture to determine which is the least of two+ evils.

* The definition issue here seems to be that I will combine such sometimes in the name of YagNi or (perceived) simplified maintenance where-as you assume they are always separated, and THAT may make it easier to classify. But '''definitions shouldn't be tied to a particular coding/design style'''. That's limiting. -t

* ''It sounds like you're trying to justify questionable coding practices.''

** Projection, perhaps?

** ''Perhaps, but there are established approaches to programming -- SeparationOfConcerns is one of them -- that are considered industry best practices.  Deliberately avoiding these approaches is regarded as inevitably producing bad code.  It is generally accepted that avoiding SeparationOfConcerns, for example, results in a BigBallOfMud.  If you're going to convince us that an alternative is not merely an excuse to produce bad code, you're going to have to produce a '''very''' compelling argument.  And illustrations.''

** Like I said somewhere below multiple times repeatedly redundantly, what people pay lip service to and what they do in practice often differ (at least that's what my eyeballs witness). And SeparationOfConcerns is an impossible request because there are multiple competing division possibilities for any non-trivial project. Excess indirection or extra steps or unnecessary MirrorModel''''''s to force idealistic "separation" can also result in a BigBallOfMud. Goto Redux.

** ''SeparationOfConcerns might '''seem''' to be an impossible request when all your concerns are the same concern.  However, it is an entirely possible request -- implemented frequently -- when developing large software systems, or small software systems of typically-diverse functionality.  Now, if you're going to convince us that an alternative to SeparationOfConcerns is valid or superior, you're going to have to produce a '''very''' compelling argument.  And illustrations.  A mere few more quips isn't sufficient.''

** SOC always occurs with SOME concerns of every non-trivial system, but almost never occurs with ALL possible concerns if the system. Agreed? Thus, in practice it's applied in some cases/aspects but not all cases/aspects, which is pretty much what I have agreed with. The issue is over WHEN to apply it and which aspects to separate on. -t


* And "important in some way" is still fuzzy. A given rule could eventually be used for only display reasons, only processing reasons, both, or neither, and change over time. '''We often cannot design our up-stream machinery based on what happens to the logs down stream'''. That's a mess, and perhaps not even do-able because the rules of modularity preclude us from knowing or caring what is done with the logs down-stream: we're just hired to do something specific with or to the logs. -t

* ''In this case, "important in some way" is merely a placeholder for what makes the list distinct.  It is precisely because "we often cannot design our up-stream machinery based on what happens to the logs down stream" that we separate business logic (the "up-stream machinery") from presentation logic (the "down-stream machinery").''

* So putting it "far away" magically turns it into non-presentation? Magic Fagic!

* [No, it being non-presentation is why we put it far away. You've confused cause and effect, there. -DavidMcLean]

* Near the opening: "Presentation logic is that portion of an enterprise system which '''determines how''' data will be displayed or reported." (Emph. added)

* [Yep, that was said near the opening and is still correct. Was that meant as a counterpoint to something? -DavidMcLean]

* The "rule" that determines which customer gets an asterisk will ALWAYS be "presentation logic" even if we put it on Pluto (lots of separation) under that def because it will always "determine how data will be displayed or reported". 

* [Correct. The separation itself doesn't magically make some particular bit of presentation logic stop being presentation logic. But the logic of "which customer gets an asterisk" may be distinguished from the business logic of "which customer needs to be sent an XYZ form", even if we want to mark customers needing XYZ forms with asterisks. -DavidMcLean]
** ''Strictly speaking, "which customer needs to be sent an XYZ form" is dangerously close to blending presentation with business logic, as an 'XYZ form' implies presentation.  Business logic would be "which customer needs to renew his/her subscription".  Presentation logic would be "send an XYZ form to the specified customer", where "specified customer" would be determined by the business logic.'' 
** It still affects the "output", and thus triggers your def's rule.
** ''Not necessarily.  "Which customer needs to renew his/her subscription" might have nothing to do with presentation logic.  However, presentation logic might call upon it to provide a customer.  That doesn't make it presentation logic, because it isn't.  It has nothing to do with presentation, and everything to do with selection of data.''
** I interpret "determines how" as synonymous with "affects", and the rule indeed "affects" the output in this case, and thus triggers your def rule. You are just adding indirection with the above, but your def doesn't use any stated indirection as a cut-off mechanism to boot such out of the def rule scope.
** [Yes, "determines how data will be displayed" is equivalent to "affects how data will be displayed", but "which customer needs to renew his/her subscription" does not affect ''how'' data will be displayed; it only affects ''what'' data will be displayed. "which customer needs to renew his/her subscription" doesn't decide if needed-renewals should be shown using asterisks, or highlighting colours, or anything like that. It just decides whether a customer needs to renew a subscription. -DavidMcLean]
** So you consider the existence versus non-existence of output of an item a different category than asterisks? I only see it as an "output granularity" issue.  The existence of an asterisk versus the existence of a piece of paper is just output granularity. Paper division is just a "big cell". It's too arbitrary of a difference. We could change the report to print multiple customers on one paper or have it one customer per sheet. We could consider the "output" the entire print stream, not just per sheet, and it's then no diff from asterisks. In short, "sheet" is an arbitrary difference maker. It affects the print stream. Further, asterisk is no more "how" than existence of a sheet. The asterisk font is "how", not mere existence.
** [True. I'll amend my later posts accordingly. -DavidMcLean]
** ''Everything between "So ..." and "... mere existence", in the edit above DavidMcLean's, is about presentation logic.  It might help to note that SQL in a business application is almost invariably business logic.  (I say "almost" because I've seen it occasionally used for presentation logic, such as having a table of menu options.''
** Arrrg. You are contradicting yourselves again. Arrrrg-squared. I better take a break from this before I say something I regret.
** [Top, you still seem to be thinking "determines how data is displayed" means "solely determines the output". It doesn't. All logic in an application is involved in determining the output; this is trivially true because any logic not contributing to the system's output in some form does nothing of value. The key word, however, is that presentation logic only determines ''how'', while business logic determines ''what''. Business logic determines things like "this customer needs to renew his/her subscription", and presentation logic decides how that should be displayed. The existence of an asterisk on a report relies on both business and presentation logic; this does not mean that business logic is presentation logic. Whether customers are all printed as rows on one paper sheet or given their own separate paper sheets is presentation. The actual data shown is independent of whether it's shown on one sheet of paper or many, however, and it's also independent of whether asterisks or colour-highlighting were chosen to display a certain fact. -DavidMcLean]
** "How" and "what" are vague or relative or interchangeable. See BusinessLogicDefinitionDiscussion.

* Please elaborate, especially near "may be distinguished". 

* [By "may be distinguished", I mean that "which customer gets an asterisk" is presentation logic, while "which customer needs to renew a subscription" is business logic. I then went on to add that this is true even if the presentation logic for "which customer gets an asterisk" is "does this customer need to renew a subscription?". -DavidMcLean]

* "which customer needs to be sent an XYZ form" would "determine how" in your phrase (what to print), and thus would be presentation by your own rule. You are contradicting yourself, unless something can be both.

* [My original example was characterising forms in a rather more bureaucratic sense than is reasonable (that customer needs to fill in an XYZ form because they haven't filled in an XYZ form!), and that may have led to confusion of presentation and business logics in the example. The replacement example, "which customers need to renew their subscriptions", is much clearer. Note that we could certainly have "which customers should be marked with asterisks" = "does this customer need to renew a subscription?", yet this would still leave "which customers need asterisks" as presentation logic and "which customers need to renew" as business logic. -DavidMcLean]

* See above regarding "affects".

* ''I think that's been addressed.''


''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 S''''''uperStar(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.)''

* That's a rather '''arbitrary distinction'''. Some situation (condition) may be determined deep in the system. Whether such situation affects only printing or some activity can change over time. It's thus not maintenance-friendly because info may be used for only printing one period, for both printing and other purposes other times, and for only non-printing purposes yet another period as requirements change. Maybe postcards are sent out to special customers during a special sale, but this sale may not lost and nobody knows whether it will be used again.

    // 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

* Further, the author of a given module may not know what the info is used for. They simply are told to make a structure which has a flag (our eventual asterisk) indicating something, and may not know all eventual or current usages of that info. The "rules of independence" of modularity suggests they shouldn't have to care and shouldn't shape their design based on the eventual usage patterns of the output. Thing about it.

** [Certainly, but the author ''should'' shape the design of a module based on its business purpose. The flag-that-will-become-an-asterisk should be described in business terms: It's not item.hasAnAsterisk, but employee.shouldReceivePromotion or product.mayBeDefective or customer.mightHaveCaughtRabiesFromDefectiveProduct. -DavidMcLean]

** Agreed, but it's not realistic for the structure of the module be dictated by what ''eventually'' uses such flags. It's too remote an issue and subject to too much change to drive the module design.

** [Yes, the structure of the module shouldn't be dictated by what eventually uses the flags. Doing so would encourage presentational information, like item.hasAnAsterisk, ending up in a module that should be solely based on business logic. Basically, you seem to be agreeing? -DavidMcLean]

** Often we don't fully know the business reason; we just know the requester wants an asterisk or marker (description may be "needs further attention by the ABC dept.". We may find out later, but I wouldn't want to hing the large-scale design around having that info versus not having it (plus it may change).

** [If we design our module around the fact that an asterisk or marker is wanted, we are designing our module around how the flag is used (to decide whether to print out an asterisk at some point, specifically). It's not realistic for the structure of a module to be dictated by what eventually uses the flags. Everything may change; if we put presentational info, like "an asterisk is wanted on this item", in our business-logic-level data structures, that inhibits change. Consider the case where the asterisk is originally shown if a customer needs to be sent a product-recall notice, then suppose there's a change, and now the asterisk is also shown if a customer's made a warranty claim. If you have fields customer.needsRecall and customer.madeWarrantyClaim, then you merely change your presentation logic: if customer.needsRecall or customer.madeWarrantyClaim then showAsterisk. If you have a field customer.needsAsterisk, you don't change your presentation logic (if customer.needsAsterisk then showAsterisk), but how will you calculate and generate the recall forms elsewhere in your application when you can't tell if customer.needsAsterisk means a recall or a warranty? -DavidMcLean]

** I'm not sure about what is where, when, and why in your description. Perhaps you could flesh it out with some pseudo-code. And per above, we don't always have clear reasons available to us. The output rules are as close as we get to clear and objective biz/processing rules because they are necessary for the immediate requirements. Our job is mostly to automate work, not classify everything. We are not building an AI empire nor educating baby Cyc.

** ''I'm surprised there's so much ambiguity in your domain that what's discussed here isn't self-evident.  In the custom business applications I've developed, the boundaries were always clear and unambiguous.  E.g., "we need to perform month-end (business logic) and generate a trial-balance report (presentation logic)." or "We need to generate an employee schedule (business logic) and be able to print work assignments from it (presentation logic)." or "We need to obtain the search results (business logic) and show them in a user-friendly fashion (presentation logic)."  Etc.  Interactive facilities bring the business logic and the presentation logic closer together -- e.g., "when you press the "Who's Available" button, find out which employees haven't been allocated yet (business logic) and show them in a list at the side of the schedule grid (presentation logic) -- but they're still clearly defined and sharply delineated.''

** I don't know why, they just are. Maybe my personality or skills somehow pair me with the type of orgs you see in Dilbert. Certain sub-domains, like accounting and payroll require well-documented rules because otherwise you get your ass sued off; but many projects bring one into fuzzy sub-domains or working with people who don't know how to describe their domain in clear English. Marketers are notorious for such, for instance. Internal department metrics are another such area because one is trying to translate a manager's notions of his/her staff's "productivity" into something compute-able. I call the environment as a I see it. Perhaps I "graduated" into such areas because I've learned to work with ambiguity and have experience with fuzzy sub-domains. Newbies are generally put on tasks that are well defined or where they are surrounded by mentors. Anyhow, I'd like to see the above change scenario fleshed out more so we can compare the alternatives and count the change impact in a hopefully objective way. It would be a refreshing break from notion-land.


* ''Indicators that affect data processing, i.e., transformation or calculation, are -- by definition -- business logic.  If an indicator is only displayed, it's presentation logic.''

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.''

* Yes it is: partition by the least-risky dividing factor(s). Partition by likely ChangePattern, not by one's particular head model. A dumbfuck's head thinks different than an idiot's head, and an idiot's head thinks different than a dumbshit's head, and a dumbshit's head thinks different than a fucktard's head. ChangePattern''''''s are not tied to a personal world view, but rather an attempt to predict an objective future. (Sure, bias will shape estimates, but at least the focus is away from a given head taxonomy and toward actual change.)

* ''I think you'll find partitioning by "least-risky dividing factor(s)" or ChangePattern''''''s will result in difficult coupling and loss of cohesion.  Is the profanity necessary?''

* In that case it would in theory hurt maintenance. You are welcome to demonstrate such. Warning: coupling and cohesion are poorly defined and thus hard to objectively measure. (As far as the cussing, I'll come back when I'm in a better mood and make them nicer.)

* ''Your claim is the exceptional one, so the onus is on you to demonstrate that partitioning by "least-risky dividing factor(s)" or ChangePattern''''''s is preferable.''

* Why is it "exceptional"? By "presentation" is not the default. (It may get a lot of lip service, but whether it's done in practice is another thing.) The default is "unknown". Both sides have to present a reason to change it from "unknown".

* ''Your claim is exceptional because it runs contrary to mainstream thinking, which is that SeparationOfConcerns should be based on functional boundaries rather than change patterns.  If you believe the primary guidelines for code separation should be ChangePattern''''''s, then that's an exceptional claim.  You need to provide evidence that P''''''artitioningByChangePatternsBeatsSeparationOfConcerns.''

* "Mainstream thinking" is a very weak form of evidence. It's not even "thinking" because the reason is not clearly demonstrated, but more like Justin Beiber being popular simply because he is popular. I expect the benefits to be analyzed and compared in a more scientific way, not the way the Catholic Church did in the 1100's.

* ''"Mainstream thinking" is not evidence.  Evidence is needed to counter mainstream thinking.  If you've got a better idea, you need to show that it's better.  This is especially true in engineering fields, where as long as mainstream thinking works it's going to endure.  The fact that it '''works''' at all -- and it may not work perfectly or even close to it, but adequately -- is all the evidence that's needed.''

* Again, what people pay lip service to may differ from what they actually do. Thus, should one do what people CLAIM "is the current way", or do what is actually being done in practice?  Regardless, all claims should be challenged. We don't mature as a society by saying, "but we always do it that way". Question authority. We want science, not authoritarian evidence. Do you want it to be "Computer Science" or "Computer Authority"?

** YagNi can also be considered a common "industry practice", and YagNi suggests don't separate until there's a clear need.

** ''YagNi is a suggestion to avoid coding functionality you don't need.  It is most certainly '''not''' a suggestion to write bad code.  If you need a given set of functionality, the YagNi test is already passed.  That functionality should now exhibit SeparationOfConcerns -- if not before ReFactoring, it definitely should after.''

** Because you say so. Got it.

** [Because the definition of YagNi says so. It's not "you aren't gonna need it" for all possible instantiations of it. It's "you aren't gonna need this particular functionality", except when you've clearly demonstrated you do. As noted, if you do indeed need some particular functionality, YagNi is already passed and therefore can have no further impact on that particular functionality. -DavidMcLean]

** Do you mean "need" a feature or "need" separation? Where is this Need-A-Tron measuring device?

** [The Need-A-Tron is something called a UseCase or a UserStory; you can tell you need some particular functionality because you have a UserStory involving it. Separation and YagNi are orthogonal. -DavidMcLean]

** My question still hasn't been addressed.

** ''If a feature is required, it's needed.  SeparationOfConcerns is always needed, unless -- and I don't advocate this as generally good programming practice, but there are sometimes economic justifications for it -- you have to write very small applications in a big hurry.''

** SOC yes, but a primary split on biz/presentation is not always warranted. (We cannot have a primary split on every possible SOC factor, at least not with current languages.)


* ''Indeed, all claims should be challenged.  I challenge your claim that SeparationOfConcerns should be along ChangePattern boundaries rather than functional boundaries.  By the way, SeparationOfConcerns is of little to no interest to ComputerScience; it's a SoftwareEngineering concern.''

* Because our main job is to strive for the best outcome. One approach to getting the best outcome is to consider the design options and do our best to predict which decision path has the best outcome. (SimulationOfTheFuture).  This to me is far more logical and rational than "do what everybody else (allegedly) does because it won't get you fired" (or who knows what the reason is). It's the science used by investors to decide among multiple choices. Why is it "good" in finance but "bad" in software engineering? Why are they diff enough to toss it for software? There are rules of thumb in investing such as "buy low sell high", but SimulationOfTheFuture will generally lead to the same thing such that they are not in conflict, but merely general versus specific. If you wish to talk about "best practices", then finance also has "best practices", including the "accepted models" of investment determination.

* ''You've provided a justification for providing an argument in favour of SeparationOfConcerns along ChangePattern boundaries.  Now, provide an argument in favour of SeparationOfConcerns along ChangePattern boundaries.  In the mean time, I'll provide a counter-argument:  SeparationOfConcerns along ChangePattern boundaries won't work in SoftwareEngineering for the same reason that it won't work in automotive design.  If we designed a car using SeparationOfConcerns along ChangePattern boundaries, we'd want to join the brake pads and intake air filter together and put them in the same housing, because they both need to be changed relatively frequently.  Obviously -- if you know anything at all about cars -- this would result in a ludicrous (and un-drivable) vehicle.  Cars are complex systems built of interacting parts.  Some parts interact very closely with each other and are part of the same concern, e.g., a transmission. That warrants making them part of the same unit.  Some parts interact closely, but are part of distinct concerns, e.g., the transmission and driveshaft(s).  That warrants making them separate, but coupled.  Some parts don't interact with each other, other than being part of the same system, e.g., the brake pads and air filter.  The same applies to SoftwareEngineering for exactly the same reason -- both cars and software are complex systems built of interacting parts.''

* But you are only focusing on one factor/metric: a service visit. If other factors are important, such as fuel efficiency, then THAT should be part of the evaluation model. From the consumer's perspective, total cost of ownership is a key metric, but also passenger/cargo space, and performance. If I'm missing OTHER key factors, please do identify them. I'm not censoring ''other'' metrics, but you need to be clear about what they are and justify their importance. Obviously software must work (do it's current job) and have reasonable performance; But our dispute about SOC hasn't touched on those so far.

* ''I'm focusing on one vital factor/metric: feasibility.  Using the car analogy (which is '''very''' apt), it simply isn't feasible or reasonable to combine the brake pads and air filter, as it simply isn't feasible or reasonable to combine functionality that is only related by likelihood of change.  Using ChangePattern''''''s as a basis for SeparationOfConcerns -- such that change is the only "concern" -- '''is''' purely a "service visit" (i.e., maintenance) issue.''

* I don't see how your car analogy maps to software. Engines are generally designed for constructability (easiest to manufacture and put together), maintainability, reliability, and efficiency.  If you put certain parts far apart from each other but they have to interact, then you need long control rods or electronic actuators (term?) to communicate motion or activity. These hurt both reliability and maintenance. But I don't know what you believe the software counterpart is exactly. Software doesn't wear out in the same sense that cars do. And "related" is generally multi-dimensional such that our grouping choices tend to be somewhat arbitrary anyhow because there are multiple interweaving grouping candidates and code text generally forces us to pick one over the others because it's linear (or 1.5D I'd say). We'd probably have to explore specific software specimen. And when you have RAM, "position" doesn't really mean much (although can affect machine performance). We can build 8D models in software if it serves our purpose, but the problem is that maintainers generally can only view 2 D's at a time. The constraints are too different in software to compare to cars.

* ''The software analogies to "long control rods or electronic actuators" are function calls and inclusion dependencies.  Good SeparationOfConcerns results in minimal, loose coupling -- a few function calls, and one external module reference, for example.  The car analogy is the drivetrain coupling between the engine and transmission -- a single shaft.  That's because the transmission demonstrates high cohesion, as does the engine, but they are (relatively) loosely coupled with each other.  Breaking cohesion in order to, say, make it easier to change the clutch -- and the clutch is the high ChangePattern item here -- would necessarily (vastly!) complicate the coupling between engine and transmission.  The same applies to software:  If we implement SeparationOfConcerns based on ChangePattern''''''s rather than functional concerns, we would inevitably need far more complex coupling between components.''

* ''If ChangePattern''''''s are an identified part of the requirements -- say, you need to alter an otherwise functionally-unrelated assortment of code chunks every time there's some policy change, such as new tax regulations -- you should still code using SeparationOfConcerns based on functional boundaries.  However, at each point where change is bound to occur, simply extract the changeable code into a new function defined in a global Policy class (or module) and invoke it.  Of course, this involves coupling with the global Policy class, but that may be an acceptable compromise if change is frequent.''

** So you say. I'm sticking with SimulationOfTheFuture as my primary decision model until somebody demonstrates using representative coded examples that there's a better alternative. Perhaps it's time to AgreeToDisagree. (By the way, consider indenting if you insert significant new material into the middle of an existing discussion. Otherwise, I might not see the change if another change masks the wiki change tool output.)

** ''I've described the nature of the code in broad terms.  No "representative coded examples" are needed.''

** It's vague.

** ''It's clear.  1. Develop your project employing SeparationOfConcerns.  2. Create a module or class called Policy (or whatever -- it's where the frequently-changing code will go).  3. From your project, extract the bits of code that are likely to change and turn them into functions in your Policy module or class.  4. Remove the code bits from your project (except the Policy module/class, of course) and replace them with calls to the appropriate functions in the Policy module or class.  5. Now you've got SeparationOfConcerns to simplify development, infrequent maintenance and re-use, with all highly-changeable code co-located in a Policy module/class for ease of frequent maintenance.''

** Your steps are based on vague sub-steps.

** ''How are they vague?  Is "create a module or class called Policy" vague?  Most IDEs have a "Wizard" to create a module or class.  What about "extract the bits of code that are likely to change"?  Extracting bits of code and moving them around, and creating functions from them, is nuts-n-bolts programmer stuff.  It's the sort of thing I could tell a junior programmer -- a technical intern, even -- and be confident it would be done correctly.  Let me know what you find vague, and I'll try to explain.''

** SeparationOfConcerns in Step 1 is vague, or at least contradicting since concerns intertwine. And we don't separate out parts that are likely to change JUST because they are likely to change. That can create unnecessary indirection or code units. ItDepends, weighed against bunches of other questions/issues. Absolute rules are usually a smell.

** ''SeparationOfConcerns is neither vague, nor do concerns intertwine.  They are distinct, by definition.  However, concerns most certainly '''interact'''.  Constructing simple, maintainable and flexible interfaces between concerns, without undue complexity or indirection, is the mark of a good programmer.  ItDepends on the specifics of the requirements and nature of the architecture how exactly that is best done, but in general, SeparationOfConcerns is fundamental to successfully implementing large projects.  Without clear boundaries between subsystems, a large project is exceptionally difficult to develop or maintain.  It becomes like a dozen cooks, all trying to fry all the ingredients at once in the same frypan.  The result is one undifferentiated mush of code -- a BigBallOfMud.  However, for small, one-off projects, SeparationOfConcerns is less of an issue -- especially if the concerns -- in their various layers, libraries and subsystems -- are pre-written.  In that case, a typical project might be a relatively short "glue" script that integrates various subsystems to solve a problem.  In such cases, the bulk of SeparationOfConcerns has been done for you, and it's merely up to you to make use of result.''

** I did NOT propose "undifferentiated code". That is flat false. I'm tempted to call it a straw-man. As pointed out elsewhere, we can only group code by one primary dimension. Spending that split on one factor wastes it for another. I choose my major divisions primarily around what I estimate as the likely maintenance patterns. Granted, there's no "free lunch" and sometimes one just has to know the shop's framework/conventions to know how and where to find and change things.


* I'm still having trouble translating between your car-speak and code comparisons. Like I said, RAM allows us not to need to care about "position", and we are limited to one primary dimension for grouping code so that related concerns must be forced apart because there are usually more than one. Anyhow, "bad coupling" would result in a poor maintainability score, although "coupling" has not been clearly and usefully defined. I suggest we explore specific examples; I doubt generalities will suffice and "coupling" is probably a messy LaynesLaw trap. Often it comes down to choosing between kinds of "coupling". -t

* ''RAM doesn't care about "position", but code does.  Partitioned code that needs to interact requires coupling, by the very definition of "interact".  Ideally, code that needs to interact should have as simple or as "loose" a coupling as possible, for developmental and maintenance ease.  Code partitioned on functional boundaries minimises coupling -- this is well-established in practice.  Code partitioned on any other boundary '''but''' functional inevitably needs more complex coupling.''

* "Coupling" is vague. There's rarely a free lunch. How about a nice Hawaiian code example. And keep in mind I am not always against partitioning by "presentation" (if such really is a clear-cut concept).

* ''Coupling is not vague.  Coupling is any reference from one component to another. Good code minimises coupling, whilst maintaining cohesion (functional relatedness of components, which ''can'' be vague though coupling is not) and modularity (SeparationOfConcerns).  What does a "nice Hawaiian code example" mean?''

* A MirrorModel increases "coupling" then.  Splitting 1-to-1 relationships into two or more increases coupling if we count named references.

* [Yes, but we don't strive for low coupling at the expense of everything else. As noted in the point you just responded to, we attempt to minimise coupling while maximising cohesion and modularity. -DavidMcLean]

* "Cohesion" and "modularity" are also vague. I minimize maintenance cost for reasons given SimulationOfTheFuture. I don't slice it based on goofy vague definitions. We are not paid to classify shit (which is an impossible job to get right), we are paid to deliver a decent product for the lowest cost in the medium term.

* [Cohesion is certainly vague; coupling is not, though, so your use of "also" is misleading. Definitions such as that of business logic versus presentation logic are not actually vague, and such a definition has in fact already been provided. As for programmers not being paid to classify stuff… we kind of are. All programming is abstraction and involves grouping and classifying primitive instructions into higher-level instructions closer to the problem domain, along with classifying those higher-level instructions as functions, modules of functions, classes if we're using OO, and so on. -DavidMcLean]

* I disagree with your clarity claims, but will leave it at that for now.  

* Re: "All programming is abstraction and involves grouping and classifying primitive instructions into higher-level instructions closer to the problem domain and classifying primitive instructions into higher-level instructions closer to the problem domain" - True, but the domain users don't give a fudge about biz-logic-versus-presentation. They don't "see" that issue, the input and output is the same to them whether it's internally separate or not.  And module-ization is to improve maintenance by partitioning along the lines of likely change and maintenance patterns.

* [Yes, domain users aren't interested in whether we've separated business logic and presentation logic properly in our code. They also generally aren't interested in whether we used for or while loops, or whether we're using an RDBMS, or whether we put methods in the most appropriate classes. All of those things are only meaningful to programmers; that does not diminish the importance of any of them. -DavidMcLean]

* As tools that do work, yes. As classification devices, maybe not.

* [Why would there be any difference? As I just pointed out, all programming tools are also classification devices, and it is as classification devices that we find many of them most useful. -DavidMcLean]

* Yes, we humans need abstractions to make software, but it can also be taken too far and forced beyond practicality.

* ''Poor coding of any kind can be taken too far.  Indeed, poor coding of any kind is '''programming''' taken to far!''

* PrematureAbstraction and excess MirrorModel''''''s is indeed often "poor coding". Stop doing it.

* ''I don't know why you think SeparationOfConcerns results in a "MirrorModel".  It doesn't, except perhaps for some abominable misuses of ORMs where you wind up with an object model in lock-step with a database schema and essentially replicate the DBMS's query language.  PrematureAbstraction is, again, poor coding.  So is spaghetti code, or poor choice of variable names.  There are a litany of coding abominations; mis-use of SeparationOfConcerns is merely one, no more insidious or likely than any other.  Good programmers can write good code in anything.  Bad programmers write bad code in everything.''

* Often it does, but not always. I suggest we explore specific scenarios, otherwise we have gajillion factors all pulling on each other if we try to make generic statements. Software engineering is about balancing myriad trade-offs; there's not free lunch.

* ''You're saying SeparationOfConcerns often results in a MirrorModel?  Could you give an example?  I have not experience this nor have I seen it suggested in the literature -- outside of complaints about ORMs, as I've mentioned.''

* See BusinessLogicDefinitionDiscussion


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

* ''I don't know what the distinction is between RealInformation/information and data, so I can't answer the first two questions.  Any mechanism that displays information "just as it is" is presentation logic.  Data, on computer systems, is stored in various binary encodings so there is no "just as it is" that is directly displayable.  Making it visible on a printout or a screen (or audio, or lines on a plotter) requires presentation logic.''

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:

* [Transformed] and/or [calculated]. For example, business logic determines [how] a tax total is [calculated] from invoice line items.
* [Routed] to people or software [systems*], aka [workflow]. 

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