Hacker News Reader

Comment by gspencley | Hacker News Reader

I would like to start by teaching developers what business logic IS, and how to separate it from the other "layers" of software design.

I can't count the number of applications I've seen that have no clearly defined "place" for business logic. So you see it buried in views, state management, persistence, databases (I'm looking at you, Postgres functions and stored procs), services, controllers ... anywhere and everywhere. Impossible to test, impossible to reuse, waiting for someone to extract and isolate it but no one seems capable of even recognizing it for what it is.

I think if you were to ask 100 developers to define "business logic" you would get 100 different answers. That's the first problem to solve.

View on HN

I mostly agree with you. But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to." And many of the remaining developers would say "what is a pure function?"

I'm not claiming that FP is always the answer, but it's a great technique that somehow is still very under-utilized despite being enshrined in popular frameworks like React (I think). I don't mean to criticize developers who are unaware of FP - I graduated in 2008 but didn't learn FP until 2014, and I still can't believe that I was ignorant of it for so long. And I can't believe how many developers are still ignorant of it. Unless I'm wrong and FP actually sucks, there is an education problem.

> But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to."

Those 10 developers might have a decent answer to the question "Where should business logic live?" (decent depending on other design considerations).

But that does not answer the question I asked them, which was "What is business logic?"

You're right. And I realize I can't answer the question. But I wonder how much it matters? If a colleague and I disagree on whether some authorization logic counts as business logic or not, what is at stake?

Business logic is often the type code that changes least. If it is well designed, isolated and organized your business logic can survive UI changes, framework changes, stack changes, database vendor changes and all sorts of other "infrastructure" change. If you can't identify that "layer" from the others, then business logic will make its way into all sorts of areas that make change harder. And the ability to change is the very value that software has to offer in the first place. If it didn't need to be resilient to change then we could stick with fixed circuits which are far less expensive to build and maintain.

I love FP; at least some aspect of it. But it’s not popular because it’s not the panacea that the evangelists want you to believe. Also, the community loves getting engaged into pseudo-intellectual ramblings that most people find useless.

Yeah that kind of stuff can definitely scare people away. I don't know what a monad is and I've stopped pretending to care. For me immutability and pure functions are the only important concepts; everything else is a bridge too far for practical corporate use. Still, I think that while null is commonly called "the billion dollar mistake", I wonder... I think that going back in time and making C# and Java immutable-by-default would have a bigger impact than adding null-safety. Maybe not a panacea, but FP does seem to set a pretty acceptable lower bound on how terrible a codebase can get in my experience.

it's clear there's no budget for maintaining that disciplined layering ... (see #3 on the list from https://news.ycombinator.com/item?id=38188689 )

to have a sacred place for business logic it'd require a nice interface, maintaining that has an overhead compared to "can't we just intercept the request at ... "

Reply on news.ycombinator.com