Typically in a system of any significant size I'll wind up with two models - a "read" model for the UI/service layer/etc... and a "write" model that houses the actual domain/business logic. When returning data as part of a web page, for example, only the read model would be used. The read model includes getters and setters, precalculated data, etc... and more often than not one can wind up creating an entity per view. How you populate this model is up to you, but I've used ORM's, views in the database which provide the data for a given entity, or in some scenarios there is an entirely separate data store for the read model, which is kept up to date asynchronously via queues, etc... from the write model. The write model follows all the rules when it comes to Tell, Don't Ask, etc... Defining a strict separation of concerns through the entire stack usually makes for a simpler, more straightforward implementation on both sides of the fence, as the write model truly only contains what it needs to do it's job (process commands coming from the user) and the read model entities are carefully tailored to fit each use case / view and you can get away from those nasty "Super Entities" that contain every possible property that might ever be needed on any given screen.

Matt Burton on the GOOS mailing list