Ted Neward has added to the "The Eight Fallacies of Distributed Computing" originally created by Peter Deutsch (and extended by James Gosling) to add two more in his Effective Enterprise Java book. Over the weekend he came up with the 11th: Business logic can and should be centralized.

The reason this is a fallacy is because the term "business logic" is way too nebulous to nail down correctly, and because business logic tends to stretch out across client-, middle- and server- tiers, as well as across the presentation and data access/storage layers.

This is a hard one to swallow, I'll grant. Consider, for a moment, a simple business rule: a given person's name can be no longer than 40 characters. It's a fairly simple rule, and as such should have a fairly simple answer to the question: Where do we enforce this particular rule? Obviously we have a database schema behind the scenes where the data will be stored, and while we could use tables with every column set to be variable-length strings of up to 2000 characters or so (to allow for maximum flexibility in our storage), most developers choose not to. They'll cite a whole number of different reasons, but the most obvious one is also the most important--by using relational database constraints, the database can act as an automatic enforcer of business rules, such as the one that requires that names be no longer than 40 characters. Any violation of that rule will result in an error from the database.

The 11th Fallacy of Enterprise Computing

More on the 11th Fallacy

Craig McClanahan responds to the 11th Fallacy

I don't fully understand AOP, but after reading the articles I think that this is a perfect example of the use of AOP. Doesn't it allow you to centralize your business logic in on "place" while still using it across multiple tiers? Like the name thing here. Put the name rule in the "rules" aspect. Every tier looks to this aspect to decide what it will do with the rule information. if its a web form, put in some javascript to defend against long names. If it is the DB then put in a varchar length of 40. if the rule changes then the individual tier will deal with it appropriately. So doesn't it make sense to Almost always centralize yor business logic in this way?

I don't fully understand AOP, but after reading the articles I think that this is a perfect example of the use of AOP. Doesn't it allow you to centralize your business logic in on "place" while still using it across multiple tiers? Like the name thing here. Put the name rule in the "rules" aspect. Every tier looks to this aspect to decide what it will do with the rule information. if its a web form, put in some javascript to defend against long names. If it is the DB then put in a varchar length of 40. if the rule changes then the individual tier will deal with it appropriately. So doesn't it make sense to Almost always centralize yor business logic in this way?

Michael,

I couldn't agree less. My understanding of AOP is that, the business rules are the various 'aspects' of the system.
We almost always have to deal with 2 important concerns while designing an application.
1)The "hierarchial relationship" between the business entities,and
2)The "business rules" which apply on the business entities.
Again,there are 2 different types of business rules
a)The rules which define the various types of interaction between the business entities. b)The rules which validates individual entities. Both these rules ,combined together,form the aspects of the system.
If we are able to maintain the "hierarchial relationship" in one single place and seperate out the business rules into a 'another layer' and

I don't fully understand AOP, but after reading the articles I think that this is a perfect example of the use of AOP. Doesn't it allow you to centralize your business logic in on "place" while still using it across multiple tiers? Like the name thing here. Put the name rule in the "rules" aspect. Every tier looks to this aspect to decide what it will do with the rule information. if its a web form, put in some javascript to defend against long names. If it is the DB then put in a varchar length of 40. if the rule changes then the individual tier will deal with it appropriately. So doesn't it make sense to Almost always centralize yor business logic in this way?

Michael,

I couldn't agree less. My understanding of AOP is that, the business rules are the various 'aspects' of the system.
We almost always have to deal with 2 important concerns while designing an application.
1)The "hierarchial relationship" between the business entities,and
2)The "business rules" which apply on the business entities.
Again,there are 2 different types of business rules
a)The rules which define the various types of interaction between the business entities. b)The rules which validates individual entities. Both these rules ,combined together,form the aspects of the system.
If we are able to maintain the "hierarchial relationship" in one single place and seperate out the business rules into a 'another layer' and empower this layer with a special feature,by letting it intercept the hierarchial relationship ,at runtime,then we are dealing with aspect oriented programming.

The main challenge,i feel,is that we always maintain the "hierarchial relationship" between business entities ,in more than one layer. The application layer ,if object oriented,provides the relationship between abstract entities,but the relationship between actual business entities is implemented in the database. Since,aspects intercepting the data layer is ruled out,it can only implement those business rules which are applicable to abstract business entities.

The another approach to this problem,which struck me often,is that we should introduce one more vertical layer ,before or after, the middle layer,which will take care of validating the business entities,since we laready have the middle layer taking care of the first type of business rules.

surajeet

I guess my interpretation of AOP was that it created vertical layers. Maybe not. Although the vertical layer you talked about is sor t of what I had envisioned.

Always the problem really: you ideally need to check your business rules (things like field value constraints) at each tier because you can't/shouldn't/didn't rely on the tier above to check those constraints... but in order to prevent unnecessary processing requests, you don't really want the database to be the "first and final check" for your data constraints (because someone leaving off their last name should give very fast feedback to the user)

Web apps are a great one: you have tiers, at bare minimum you have client and your webapp server tier. Generally you'd use javascript or something to catch the easy errors, like forms not having all mandatory fields filled out, number of characters etc.. But you can never assume this will take place (can just turn off js, or manually hit the URL). So even with just two tiers there is a need for two lots of code to enforce the "this field needs to be filled out" rule. Add in a typical database as well and you now have the "need data" rule present in javascript, jsp's/servlets/javabeans, and in your table schema.

Say I now want to change that business rule about the data.. I have to change it in each of the tiers. Which is all well and good until I forget to change it in one spot. So what's really needed is to centralise the business rules and distribute the various "engines" which can apply the business rules.

As yet, I haven't come across anything which does this across everything.. Fair enough across javascript and jsp/servlets, but across anything further back it starts getting a bit messy (the database is the killer I think.. without some messy stored procedures or else regenerating the table constraints all the time.. ).. But taking that approach you can perhaps have the "centralize business logic", all it has to do is have a sophisticated enough set of engines and a rich enough language to describe the business constraints on the data.

That's at least some ideas on the data constraint aspect of business "logic".. Guess the same could apply for some of the business processing logic.. Though generally the actual processing type logic need take place only on one of the tiers. and you have to ask: at what point does trying to centralize things make the application less reliable/understandable/maintainable/realisable/testable through trying to use generic declarations of the business logic versus just coding the business logic where it needs to be..

regards,
Nathan Lee

It's one of those quixotic crusades of mine, I firmly believe that all non-layer specific logic can and should be encoded in a way that is applicable across all the layers.

What exists on almost all the layers? The humble DTO.

It's always irritated the heck out of me the insistence that we be as un-object-orientated as possible and keep all logic out of these objects. Most arguments against it assume that it's an all or nothing propositions - All logic or no logic. No it isn't, just put the layer independent logic in.

I've heard some very specious arguments against this before, the real humdinger was the one that it would cause the communications to slow down because of all that logic that had to be transported between layers.

I admit that this is likely to be flame bait - but consider this point, you can localise a lot of business logic to just one set of classes, nicely satisfying DRY. The checks are performed on multiple layers, but isn't that the point?

If you want to go a little further you can make the DTOs use a validation factory to perform layer specific checks.

Bob Boothby.

The humble DTO.It's always irritated the heck out of me the insistence that we be as un-object-orientated as possible and keep all logic out of these objects. Most arguments against it assume that it's an all or nothing propositions - All logic or no logic. No it isn't, just put the layer independent logic in.

Now this is going down to the level of mobile code, even perhaps templating that can be transformed on each node in the layer.

This is where things like Jini and agents come in, because we have mobile objects and Java's ability for mobile code (and with Jini, secure, location-independent mobile code), and agents can extend an object's capabilities to not only represent attributes and behaviours, but also a concept of location/environment.

The DTO point, annoys me as well. Sure, make a coarse grained object because we need to reduce number of transfers, but that doesn't mean that all the logic should go out of it. Take JavaSpaces and Entries, these can be (and are looked up as) basic DTO's but there is _nothing_ that prevents the Entry classes from having behavioural methods.

The issue is that if the IT world is moving (or insisting we move) to a Service Oriented Architecture, the problems of the basic DTO will come to the forefront. We need SOA simply because we are getting to the point where you can't put all logic in either one layer or one machine, due to various reasons, such as massively heterogenoeous environments, different operating systems, mergers and acquisitions, and even something as banal as office politics.

When I read Deutche's fallacies:
http://today.java.net/jag/Fallacies.html
 
They appear to fall into a different category than what Ted is throwing out there. Ted's statement reads more like an anti-pattern to me than a fallacy. I'm certainly in favour of exploiting the database for enforcing data relationships for example (at persistence time) - and for simple SSN validation why not do it in the web tier? As with most things in s/ware engineering, I think it is dangerous to get too dogmatic about these things.

As I work on the ILOG JRules product I also get to see a lot of business rules. Most are significantly more complex than the simple field validation examples cited here. In many cases there are thousands of business rules being maintained by dozens or hundreds of business users (not developers). In these scenarios (insurance, banking, car hire for example) there is a enormous amount of value in centralizing business rules. Additionally government compliance regulations may make this a requirement for accurate audit purposes.

Sincerely,

Daniel Selman

I think this is a really good blog, but the examples about storing business rules in the database generating a lot of server requests sort of misses the point.

Rules like this should be enforced at the user interface level because they make it better for the user.

Choice A) Allow the user to enter as many characters as they want and send the data back to the database. The database either truncates the data or sends back some cryptic error to the user about how "table.column constraint x violated" and the user has no idea what's going on.

Choice B) Let the user enter whatever they want, but if they enter too many characters pop up a javascript alert window when they submit that tells them in English.

Choice C) Limit the number of characters the user can type. When they get to the maximum length stop accepting input and give a beep.

Choice B and C are equally efficient in terms of server hits, so the programmer should be free to choose either. Wrong, choice C is better for the user. They get immediate feedback of their mistake, no intrusive popups, don't have to look at the screen even to know what's going on, etc...

Programmers spend way to much effort trying to do all this stuff to make the computer happy and forget that at the end of the day all this stuff is for humans. Centralizing all the rules may make a program more efficient or easier to maintain, but can be murder on the end users.