
A Working Definition of Business Logic, with Implications for CRUD Code  - KiwiNige
http://database-programmer.blogspot.com/2010/12/working-definition-of-business-logic.html
======
baddox
I don't think his definition is completely satisfying, but I love this
discussion since developers so often use the term "business logic." It's one
of those terms that we can't immediately define, but we _just sorta know_ what
it means. If it looks like business logic, talks like business logic, you know
the drill.

I've noticed a similar idea when trying to classify issues in an issue tracker
for a software project. We realized that using tags called "cosmetic" and
"feature request," it sometimes gets hard to distinguish between the two,
especially in GUI (or web) applications.

~~~
elblanco
A terrible amount of the effort in modern enterprise software engineering is
bridging the gap between business logic and code. Layers upon layers of
diagrams and modeling techniques and pseudo-code systems are all purely
intended to try and take a very high level and abstract business concept and
bring logic and discipline to those concepts until they reach a level they can
be instantiated in code.

[http://en.wikipedia.org/wiki/Business_Process_Execution_Lang...](http://en.wikipedia.org/wiki/Business_Process_Execution_Language)
<http://en.wikipedia.org/wiki/ArchiMate>
<http://en.wikipedia.org/wiki/TOGAF#TOGAF_8_Certified_Tools> etc. etc. etc.

All of the above (and more) are the wild shots in the dark to not only bring
engineering discipline to business folks, and to supply a common language
between equally intractable engineers and business people but also to prevent
blame coming from both sides (which can get really ugly at times as engineers
try and interpret wildly abstract and often contradictory business ideas into
a working system, and business folks thinking that engineers don't understand
basic business concepts).

That all being said, I don't think it's entirely working (as several very high
profile, very expensive, Enterprise Software failures have demonstrated). It
requires business people to learn a modicum of technical and logical skills to
fill out the high level models, and it takes engineers out of their
development time to drag it down through the rest of the levels of abstraction
to get to actually getting down to working. Then they have to validate
conformance to spec with entire trips up and down the abstraction stack.

 _sigh_ Of course this is probably the best way we know so far to build
monstrous systems but it's clear we still have a long way to go.

