>
> Now we could adapt our Invoice class to contain an Orders attribute which
is
> an array of Order business objects.

I will not say this is necessarily the wrong approach, but it is a pitfall
in OO design: You have orders and invoices hence you necessarily have order
and invoice objects.

But it might be the orders and invoices were better off as database records
and what you really need is an order-processing object and an invoice
archiver object. The real inherent objects in the problem being solved are
not always obvious and it is an art to figure them out. There has been
written much litterature on how you can harvest good objects and weed out
bad objects using different strategies. I'm not convinced how well it works
following such strategies as written in a book - but one should seek to find
the nature of the problem somehow - and I guess the best approach is rather
individual.

Mikkel