A Working Definition of Business Logic, with Implications for CRUD Code

A Working Definition of Business Logic, with Implications for CRUD Code (database-programmer.blogspot.com)

11 points by KiwiNige 15 years ago | 3 comments

baddox 15 years ago |

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 15 years ago | |

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

KiwiNige 15 years ago | |

I'm interested to see where he goes with this line. A checklist of Business Logic items could be very powerful when collecting user requirements. Although I would expect that it would always be missing something and would need to be flexible depending on the project.

It also means that your system is partially (or more) documented from the start which would save some effort when before you hand it over to the customer or support team.