+1  A: 

The way I see it, you have two possibilities:

  1. Have the lower layers send up all the information they have about a person, possibly as an XML document, even though many of the consumers of that information don't need it all.
  2. Provide APIs for the higher level layers to drill down and get the information they need. So in the case you give, have a method that the interface can ask the business layer to ask the database layer for the department given the user id.

Both have trade-offs. The first one exposes a lot more information, possibly to consumers who don't have any right to that information. The second one passes a lot less information per transaction, but requires more transactions. The first one doesn't require a change to the API every time you have more information, but changes the XML. The second keeps the interface of existing APIs the same, but provides new APIs as needs change. And so on.

Paul Tomblin
Right, neither of these feel good to me. For instance, if we only send up what is needed by the controller, we need, as you say, for a way to say "Well, I need more", and this would have to be as lean as possible, not execute one sql per employee...
Lasse V. Karlsen
@lassevk - Like I said, it's a trade-off. You have to decide which trade-offs work best for you.
Paul Tomblin