Syndicated from ebizQ
Jeff Attwood had a great post over on Coding Horror – All Abstractions Are Failed Abstractions in which he discussed a Joel Spolsky article in which that states
- Advertisement -
All non-trivial abstractions, to some degree, are leaky.
At some level, of course, this is true and Jeff goes on to say
More Read
But I’d also argue that virtually all good programming abstractions are failed abstractions. I don’t think I’ve ever used one that didn’t leak like a sieve. But I think that’s an awfully architecture astronaut way of looking at things. Instead, let’s ask ourselves a more pragmatic question:
Does this abstraction make our code at least a little easier to write? To understand? To troubleshoot? Are we better off with this abstraction than we were without it?
And that, of course, is the critical question. And that brings me to business rules. Business rules, especially when business users are brought into the picture to collaborate on their creation and maintenance, are an abstraction for the hard-code logic that will be executed. And they almost certainly meet this definition of a …
- Advertisement -
Copyright © 2009 James Taylor. Visit the original article at Business Rules are a failed abstraction – so what?.
Syndicated from ebizQ
Jeff Attwood had a great post over on Coding Horror – All Abstractions Are Failed Abstractions in which he discussed a Joel Spolsky article in which that states
All non-trivial abstractions, to some degree, are leaky.
- Advertisement -
At some level, of course, this is true and Jeff goes on to say
But I’d also argue that virtually all good programming abstractions are failed abstractions. I don’t think I’ve ever used one that didn’t leak like a sieve. But I think that’s an awfully architecture astronaut way of looking at things. Instead, let’s ask ourselves a more pragmatic question:
Does this abstraction make our code at least a little easier to write? To understand? To troubleshoot? Are we better off with this abstraction than we were without it?
And that, of course, is the critical question. And that brings me to business rules. Business rules, especially when business users are brought into the picture to collaborate on their creation and maintenance, are an abstraction for the hard-code logic that will be executed. And they almost certainly meet this definition of a failed, leaky abstraction. Many programmers reject the use of business rules because of this.
When a programming blog linked to my article on using business rules rather than soft-coding lots of programmers responded. Underlying the reasons they gave for rejecting business rules (which I discussed in a series of posts – 1,2,3) was a sense that business rules are an unnecessary and failed/leaky abstraction. But if you ask the question Jeff asks – does it make the business logic easier to write, to understand and to trouble shoot – then business rules are, as I argued, a compelling abstraction. In particular:
- Advertisement -
- Business rules use fewer words, fewer lines of “code” to describe complex logic than procedural languages do
- Business rules are easier for those who understand the business to understand and thus to validate (and who else is really in a position to tell if you if the logic is what the business needs)
- Because they are atomic and independent, business rules either fire or don’t fire and so troubleshooting is easier.
So are business rules a “failed” and “leaky” abstraction? Probably. Should you use them anyway? Yup.
