>> In short when you look at how our economy is structured, the whole thing is a series of abstraction layers. <<

Abstractions, yes. "Layers"? Not really an appropriate description IMO. The abstractions are graph-structured "views", and not so much nested "layers".

>> At every layer, whether it is between businesses or between people within a business, there is a hiding of details that the person asking doesn't need to know which really do need to be known to satisfy the request. That isn't theory. That is specialization in action, and was documented centuries ago by Adam Smith. <<

Yes, but graph (webbed) views, and *not* really layers. Roles, filters, call them whatever you want, but "layer" implies something higher or lower than the other, which is not appropriate to a relativist like me.

Some details for a secretary are not important to the boss, and visa versa. For example, the boss may see HR details of an employee he is about to fire. However, the secretary may only see a note to remove the fired dude from the mailing lists. She sees less, he sees more.

But, if she is asked to schedule a meeting, then the boss may only see the final time slot, whereas she may ponder several candidate time slots. In this case, she sees more and he sees less. (The opposite of the fire example.)

(I realize the genders used here are stereotypical, but making them PC would be more typing to make things clear.)

IOW, the "level" of details in this example is independent (orthogonal) of the employees' rank. Further, attaching behavior or detail level to rank is too heavy coupling because the tasks may be reassigned or rearranged later. Thus, one should use a very light form of coupling, such as tables of access rights, for example, instead of hard-wired "types".

Things change.

>> Explain it in terms of actual people doing real jobs, and you can see it in practice. <<

Yeah, teams temporarily or permanently coming together to solve a given task. Sounds very p/r to me.

>> What actually happens is, of course, wildly different based on what the protocol is. But you don't know, and you don't care. <<

Exactly. Whether the protocol *internally* selected is based on polymorphism, case statements, or a table lookup is hidden away from the user of such thingies. I have a whole webpage devoted to "swappable device drivers" bringing up many of these philosophical issues. I would note that in biz apps, the division between "types of drivers" may blur, as the programmer is not trying to make a commercial-grade super-generic driver or split them up into different DLL's for shipping purposes.

Thus, if two different "drivers" share enough code, then they may be merged and the differences managed with say IF/Else statements. Generally if more than 50 percent is the same, then merge them and use IF/Else statements to select the differences. However, if less than 50 percent is the same, then make them two different modules and call the shared parts.

Your example is kind of a systems software example. I would like to see more of a *business* example. (I might look at it closer during the weekend regardless.)