I recently read this post by Rocky Lhotka about the importance of where to place business rules when designing software.  My reply, along with an answer to my own question, is reposted here.

I must say I agree with you on this topic; I don't know anyone who doesn't.  I have developed a few applications in VB 6 (yes, VB version 6) and C# using this approach.

It IS very, very difficult to implement in any but the most simple of applications, however.  Unless you are very careful, it is very easy to have all your layers working properly and then still find business rules being placed in screens, forms, and services.  In the majority of business applications that I've put together, the same business object is used in multiple screens, forms, and services.  The problem is that, usually, each one requires that different - conflicting - sets of business rules be placed on the same object.  There are many design choices when faced with this situation.

1.  You can wire each screen, form, or service with the rules.  Obviously, some of the rules will be duplicated.  This is exactly what we are trying to avoid.  It is, however, the easiest to implement; especially since many UI actions occur based on the results of some of the business rules.  It's a trap!  Don't fall for it.
2.  You can clutter the object with "condition" settings and apply rules based on the conditions.  I've seen this done many times and I hate it.  Talk about a maintenance nightmare...
3.  If the screen, rule, or service requires a special set of business rules, you can create a separate business object for each; inheriting from the business object that provides the most complete set of rules for the designed purpose.  This sounds good.  Business Objects contain all the business rules.  Screens, forms, and services don't have duplicate rules to maintain.  Maintenance can still be a pain in some cases, though.  When a new rule must be created, care must be taken to position it in the right business object so that it is inherited only where required.  It is very easy to find duplicate rules in this setup after a few months of maintenance kicks in.

Of these options, I like number three the best.  But I find that most people first choose option 2, then find themselves wishing for something different.

If anyone knows of other options or approaches, I'd love to hear about them.

Now all this said, I have to laugh at this statement from your post, Rocky:
"The resulting applications are very fragile and are impossible to upgrade to the next technology (like .NET). Today, as we talk, many thousands of lines of code are being written in Windows Forms and Web Forms in exactly the same way. Those poor people will have a hell of a time upgrading to WPF, because none of their code is reusable."

This strikes me as "funny" because every time I've upgraded an application to the next technology, it required a complete rewrite from the ground up!  The rewrites aren't necessary because business rules are placed in forms, screens, and services - but because the code wasn't transferable to the new technology!  Even upgrading from .NET 1.1 to .NET 2, or .NET 2 to .NET 3, how much of the code is going to transfer cleanly?  That's just code.  Usually an upgraded database is involved, too.  SQL Server 2000 to 2003 or 2005, for example.  Coding technology, databases, and even hardware are changing so rapidly that keeping up with it all is practically impossible.

Really, does ANY of this really matter?

My Answer:  Yes!  It does matter.  Some day, hopefully sooner than later, there will be a "universal" understanding of how to design and write code for these situations.  I thought XML, or some cousin, had a chance of helping in this arena.  Perhaps it still does.  For now, though, it seems to have hit a wall.

All the discussing and swapping of ideas leads us closer to this magical day.