Understand on what level?

The basic idea is that dbus is a type of communication layer and api.
Services can register there and programs see their registrations. dbus can in theory then launch a service too, so things don’t have to run all the time.
The idea is similar to having some known config file, that programs write to and that a service listens on or uses later. But dbus has more granularity.

It also often runs the other way, with system components presenting info in dbus and programs using it, to adapt to user configuration.

And let’s not even get into udev.

Point here is that dbus could be implemented via a command and an sqlite database for example. The command checks the database and constructs the dbus state from it.
But for likely performance reasons it isn’t, so this info is simply hidden in dbus, in ram, instead of being a file.

You can access dbus via a socket file ofc, but it’s not like you can mount it.

Even more confusingly, the internal ephemeral dbus structure with its apis and endpoints resembles a filesystem. In that way it is similar to the w!ndows registry, though not nearly as bad.

so yeah dbus is most definitely not files

edit: also there’s multiple dbusses, usually one per user and one for the system. Those two hold different apis and info. It’s just the same thing twice tho.