Exposing your business logic layer II

I got some comments to my previous post. I never know if I should answer them in the comments section or in the weblog itself, as I never know if someone reads the comments, so I'll post this here.

I'll try to explain myself with an example and a couple of questions.

Imagine you have a domain model with 100 classes (which is a small/medium sized enterprise application) and suppose you want to give the UI programmer a way to work with an Invoice. You want him to create an ASP.NET UI app that inserts and displays Invoices.

In the object model the Invoice class is related with Customer, Products, Categories, ProductPrices, Countries, Shipping Methods, and probably more classes.

Should I give him the Invoice class that eager or lazy loads the full object hierarchy, probably giving him much more data than he needs, or should I create an InvoiceUI class and load it with just the data he needs for the Invoice?

Also, which structure will be more stable? My domain model around the Invoice or my InvoiceUI class? The InvoiceUI class almost never changes, just when I want to add or remove something from the Invoice. The domain model changes each time I need to refactor one class in the model.

Is there a pattern in Martin Fowler's book for this? I lent it to a friend so I cannot check it. I really don't remember one that matches this strategy.