X11 is a process, whose responsibility is listening to input devices and writing to the screen. (How it handles this is another question, rather more complicated.) Processes talk to X11 via either Unix or TCP sockets, depending on configuration (if it's Unix sockets, the socket files are usually under
/tmp/.X11-unix). Any process which deals with X is talking to X11 over one of those sockets; there's no intermediary in the communication itself (unless you're using a nonstandard setup such as SSH forwarding or xpra).
The window manager is a separate program, which also talks to X11 using the X protocol on a socket. It uses a separate set of APIs X provides, which allow it to issue directives to other applications on that particular X11 instance; it may also issue drawing and input requests itself, e.g. to draw window decorations (such as the usual maximize/minimize/close buttons and title bars) or to respond to global shortcuts (on modern systems, usually Ctrl-Alt-Del is handled here). Note that the window manager indeed only issues directives to the other X programs, not direct orders; programs are capable of ignoring them, if they take some special steps. (The situation is a little more complicated with a compositing window manager, since that also handles the actual graphical rendering to the X server as an intermediary for the applications.) All the communications that take place here are occurring over sockets using the X protocol.
A desktop environment is a suite of programs which do various things. Usually the window manager is included in this; it also may include some set of graphical configurators and utility programs, a file manager integrated with the desktop, a system tray to display miscellaneous status updates, and so forth. Most of this isn't particularly mysterious, just more X programs which render to the X server. Where they have to communicate among themselves, they use their own protocols, usually using sockets of some kind as a backend. Recently, the trend has been away from applications writing their own protocols and toward using higher-level metaprotocols such as