This diagram is a logical map, not an explicit map of how everything actually gets implemented. In reality, Direct3D and DXGI are more 'side-by-side' and the layer that includes the User Mode Driver (UMD) and the Kernel Mode Driver (KMD) is the Windows Display Driver Model (WDDM) which uses the Device Driver Interface (DDI) to communicate to the kernel mode which in turns communicates with the hardware. The various versions of Direct3D are also 'lofted' together to use the same DDI in most cases (i.e. Direct3D 9 an Direct3D 10 legacy applications end up going through the same Direct3D 11 codepaths where possible).
Since "DXGI" means "DirectX Graphics Infrastructure" this diagram is lumping the DXGI APIs with WDDM and DDI.
The purpose of the DXGI API was to separate the video hardware/output enumeration as well as swapchain creation/presentation from Direct3D. Back in Direct3D 9 and prior, these were all lumped together. In theory DXGI was supposed to not change much between Direct3D versions, but in practice it has evolved at basically the same pace with a lot of changes dealing with the CoreWindow swapchain model for Windows Store apps / Universal Windows Platform apps.
Many of the DXGI APIs are really for internal use, particularly when dealing with surface creation. You need to create Direct3D resources with the Direct3D APIs and not try to create them directly with DXGI, but you can use QueryInterface
in places to get a DXGI surface for doing certain operations like inter-API surface sharing. With Direct3D 11.1 or later, most of the device sharing behavior has been automated so you don't have to deal with DXGI to use Direct2D/DirectWrite with Direct3D 11.
The real question is: Why does it matter to you?
See DirectX Graphics Infrastructure (DXGI): Best Practices and Surface Sharing Between Windows Graphics APIs