UI and domain code

Although I am more of a back-end programmer I have worked with some, albeit, rudimentary webpages, recently in seaside. I've often thought of the mismatch between domain code (the model) and the view that we create around it to manipulate the domain.

What is this mismatch? It seems that there are a couple of camps on how to create an application layer around a model where either you create fine grained Transaction Script code or more coarse grained Transfer Objects with domain Commands to perform the business functionality.
The problem I feel is that business-domain-model code then moves into the application layer (most people create Commands that are nothing more than a glorified Transaction Script). The problem is your business-domain logic is in the wrong layer and therefore business rule consistency and re-use is diminished or hard to separate due to the coupling.

Trying to follow a design with a rich domain model I would say that an application should have it's own application-domain-model (idealy with its own well defined bounded context and a mapping layer to the actual business-domain-model below), and this application-domain-model would drive the business-domain-model code.
It feels like most people see MVC very explicitly and would like to have 'business objects' (objects persisted to a DB) with a view/presentation aspect and then a thin and very direct user gesture interpreter to manipulate the objects and satisfy the business rules. Now in simple CRUD applications this is fine, but when we have rich business-domain-models I can't see how this solution would scale. Abstractions would start to leak out, coupling would occur between application code and business code, and generally the 'application' logic cannot be reused/reappropriated on a different UI. What I'm trying to say is that a web app cannot be changed to a J2ME app as the app code is very specific.

Why aren't we creating an application-domain-model that abstracts what the app is trying to achieve and then we may be able to cater for different UI/interaction models over it. Also we would be encapsulating the application state/process-logic from the business-domain-model.

Some disclaimers: this is a rambling post because I'm not sure what the right answer is, all business problems are very different in complexity and so these arguments won't hold in all situations.

Funny enough what I wanted to talk about was Magritte which is dynamic meta-description framework for domain objects which helps developers to build different views, editors, and reports; and handle querying, validation and storing domain objects in an extensible and easy way.

Well I'll leave that for another post and maybe think more of the application-domain-model vs business-domain-model issue...