A large part of architecture thinking is about separation of concerns. We try to isolate businessy stuff from other stuff. You'll often see discussions start with three layers:
presentation <-> business <-> persistence
It's challenging to keep business rules out of presentation, but well worth while. One classic benefit is that you can plug multiple presentations into the same business. My project has a web presentation for humans and a SOAP presentation for other systems. Keeping business rules in the business layer assures that any client will get the same results.
You can break business stuff down again. You mentioned Facades. They give a simplified interface for presentations to call, but shouldn't do much business unless you're sure you can force all clients through the same facade. There are many other ways to slice up business logic - common objects that are used by multiple applications, application-specific objects, objects responsible for individual business transactions, etc.
Is that a helpful start? Does it raise new questions? [ September 24, 2004: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi