DIX and DDX
The X server's split into a machine-independent core that speaks the protocol and a hardware-dependent layer that draws: the 1987 blueprint every X server still follows.
The sample server MIT shipped with X11R1 was written at DEC's Western Software Laboratory by Phil Karlton, Susan Angebranndt, Raymond Drewry and Todd Newman, and their document on the server's "porting layer" cut it in two. DIX, Device Independent X, receives protocol requests, keeps the window tree, resources, atoms, grabs and selections, and delivers events to the right client. DDX, Device Dependent X, is everything that touches a particular screen or input device: setting up the framebuffer, filling rectangles, moving the cursor, reading the keyboard. Between them sits mi, machine-independent fallbacks that draw in software when the DDX has nothing better, plus an OS layer for sockets and authentication.
In the source tree DIX is the dix/ directory and DDX is hw/, where hw/xfree86 with its xf86-video and xf86-input drivers is the server most people mean by X.Org. But Xvfb, Xnest, Xephyr, Xwayland, Cygwin's XWin and XQuartz on macOS are also just different DDXs on the same DIX. The boundary is a table of function pointers per screen, and extensions such as Composite and Render swap the pointers out and call the original afterwards, a pattern X hackers call wrapping and everyone else calls unreadable.