Let me give you a concrete example of the purpose of the dependencies.

Let's say in the Domains default workspace of the Domains project area I create an ontology (O1) with a class (C1).
Still in the Domains workspace, I create a domain (D1) with ontology O1 and the class C1 as a top level document class.  (I also added the appropriate editor definitions.)
Now I create a snapshot of the Domains workspace.

I now create a different project area, and in the settings I choose the Actively managed with Design Manager option.  In the Domains section, I associate the domain D1.

Now, in the different project area, I can see the option to create C1 in the Designs menu in the Create Design Resource section.

If I were to go back to the Domains default workspace of the Domains project area and add C2 to the ontology and as a top level document class of the domain, I would not see the option to create C2 in the Designs menu in the Create Design Resource section in the new project area.  I still only see the option to create C1.  That's because it's dependent on the previous version of the Domains project area.

This is where the effect of the dependencies comes in.

To have C2 show up, from the Current Configuration Context menu of the project you just created, choose Open Current Configuration (the help instructs you to choose Explore Configurations and doesn't explicitly mention the step of clicking the actual configuration) and click on the Dependencies tab.  You will see the dependency on the first snapshot you created (i.e. the one you created after only adding C1).  Choose Add Configurations, check the checkbox for the second snapshot configuration, and press Add Selected.  Now, when you go back to the project area you just created and refresh the page, you will see the option to create C2 (i.e. the resource shows up in your second project) because a dependency has been added to a snapshot in which C2 exists.