I have an eCommerce website and I like my projects very n-Tier/Loosely Coupled/highly extensible.
This project is in MVC 3, a Domain Library, a Service Library, and a Data Access Library (repository pattern).
However, I'm cautious as to the implementations of wide scale constant business rules like temporary store-wide discounts, and minimal deposit fees would/should be placed.
In my view, any business rule which deals with allowed states of the data should be enforced in the database. That includes valid individual values as well as valid relationships among values. When you get to process validation, it should be moved to a layer which deals with process. For example, whether a particular state is allowed to transition to another particular state is something which probably doesn't belong in the database, but likely belongs at the next layer up from it.
The various constraints available in SQL, as well as database triggers are good for enforcing rules about allowed state. If a validation involves multiple rows or tables, you may need to worry about transaction isolation level and/or explicit locking to get it right, and those are database features.