There may be Value objects that the business layer uses to communicate with the presentation layer. These may or may not be passed on from the data layer. We are considering a category of VO's that are only used between the business layer and the presentation layer to be called Transfer Objects to distinguish them from traditional VO's.
(The business layer does not know what the presentation layer, or client is. It could be a web page, a web service, an XML document, or even another application.)
In the example of an invoice, since each detail line of the invoice is itself a VO, and can be manipulated independantly of the header data (and in many instances are, for example totaling an order does not require the header at all.)
Since header data can stand alone, and detail data can also stand alone, they are each represented by VO's. I guess it would make sense to have an invoice VO that would model the relationship between them, with an embedded header VO and a container with all the detail VO's
The difficulty (at least conceptually) is that modeling the order structure within a VO seems to violate the purity of the object. We only allow getters, setters, and a to string method in a VO.
As far as the relationship between a head and detail being business logic, while it is somewhat subjective, it really is a business model that drives this relationship.
I have worked with transactional systems that were designed such that an 'order' was a single record in which the header and detail information were together.
This system only allowed a single item on a transaction. In this case the business logic dictated a single object per order, whereas our business logic dictates multiple objects per order in an hierarchy.
In fact, if you really want to get a feel for the relationship, here's a quick overview (still omitting some information for clarity):
* Order header (1 per order)
* Order detail (1..N per order)
* inventory allocation (1..N per detail)
* Allocation packaging (1..N per alloc)
* Order total (1 per order)
* Order Packaging (crosses multiple orders & details)
It gets complex fairly quickly.
Hopefully this helps to understand where I am coming from.