A recent pet theory of mine has been that in object-oriented systems, where there are bidirectional relationships, one of the directions always consistently dominates.
I have no proof or logical argument for this, per-se, just intuition that it makes sense, and an overwhelming collection of positive examples.
For example, a form might create a number of text fields and position them on-screen, but you might want a text field to grow when its input gets too long. Then the child (the text field) is advising the parent (the form) about how big it wants to be. But this relationship is asymmetric because the parent might well ignore the child's size preferences (maybe the overall form size is too tall), yet the child is positioned exactly where the parent puts it. And of course, the parent knows the specific identity of the child, but (we hope) the child doesn't know much about the parent.
Similarly, information from a database query flows into a list, and actions from that list might insert or remove elements. But here, too, the list is deferent to the database, which could reasonably reject those actions.
Henrich Apfelmus has thought about this specifically for the case of data flow in GUI elements, but I think the principle applies more broadly in object-oriented and actor-like systems. Which makes me wonder about architectural patterns which make sense only in one direction (e.g. chain of responsibility), or whether there are special compositional considerations which are direction-independent.
One thing that confuses me about this conclusion is: logic programming systems do
seem to have symmetric bidirectional relationships. For instance, I can legitimately say "button A is 10px to the left of button B" and "button B is 10px to the right of button A", and have a constraint solver system find a sane solution, but the relationship between A's position and B's position really has no dominant direction.
 FRP - Three principles for GUI elements with bidirectional data flow