D-Bus 深深地受到了DCOP系统的影响而且在KDE 4中取代DCOP；他已经被实做在Qt4, GNOME，Windows以及 Maemo 行动系统中。GNOME也逐渐的用它来取代了大部分的早期Bonobo机制。
介绍
D-Bus 允许程式在其上注册以提供服务给其他的程式。同时他也提供客户端程式查询有哪些服务是可得的可能性。程式也可注册以等待kernel之events比如说硬体的热插拔。
D-Bus 被以daemon的方式实做。使用者可以执行好几个D-Bus的实体，每个实体被称为一个channel。通常系统中会有一个特权的channel称之为system channel，以及每个使用者拥有一个私有的实体。使用者需要私有的实体因为system channel将有存取的限制。
System channel主要的功用在于传递HAL的讯息给对这些讯息感兴趣的processes。而私有的实体之功能在于提供程式间无限制的沟通。
架构D-BUS是一个设计目标为应用程序间通信的消息总线系统。它是个3层架构的进程间通信（IPC）系统，包括：
函数库libdbus，用于两个应用程序呼叫联系和交互消息。 一个基于libdbus构造的消息，总线守护进程可同时与多个应用程序相连，并能把来自一个应用程序的消息路由到0或者多个其他程序。 一系列基于特定应用程序框架的Wrapper库。 D-BUS为了两个特定情况而设计：
同一个桌面会话中两个桌面应用程序的通信，可使得桌面会话作为整体集成在一起以解决进程生命周期的相关问题。 桌面会话和操作系统的通信，这里操作系统一般而言包括内核和系统守护进程。
D-BUS运作方式所有使用D-BUS的应用程序都包含一些对象，它们一般映射为GObject、QObject、C++对象、或者Python对象（也许不需要）。一个对象是一个实例而不是类型。当经由一个D-BUS连接受到一条消息时，该消息是被发往一个对象而不是整个应用程序。
为了允许消息能指定接受对象，还要提供引用对象的方法。在你偏爱的编程语言中，它也许叫做指针或者引用。但是上述所谓引用一般实现为与应用程序相关的内存地址，因此无法在应用程序之间传递。
为了解决这一问题，D-BUS为每个对象引入名字。这些名字看起来像是文件系统路径，例如一个对象可能叫做“/org/kde/kspread/sheets/3/cells/4/5”。易读的路径名是受鼓励的做法，但也允许使用诸如“/com/mycompany/c5yo817y0c1y1c5b”等，只要它可以为你的应用程序所用。
Namespacing的对象路径以开发者所有的域名开始（如/org/kde）以避免系统不同代码模块互相干扰。
