Docbase should be thought of as a huge centralized repository that stores content and metadata in the form of ‘objects’ and their properties.

docbroker-architecture

Figure “Docbase structure” depicts the Docbase as a logical unit comprising of content files, RDBMS (database) tables and full-text indexes..
Docbases are now called repositories, in 5.3 and later documentation except where the term “docbase” is used in the name of an object or attribute (for example, docbase config object)

Whenever a client wants to make a connection with the server, DocBroker acts as a bridge or an intermediary. (Please refer to figure docbroker arthitecture)

DocBrokers are now called connection brokers in 5.3 and later documentation

A DocApp is nothing but a packaging unit for Documentum objects.
A DocApp works as a deployable packaging unit to move objects across Docbases.

Using Documentum Application Builder you can create and package all your objects within a
DocApp (refer to Chapter 2). In our case, we created a DocApp with the name TestDocApp to
include our custom Documentum objects. Once all the objects have been packaged within a
DocApp, you can create a DocApp archive using Documentum Application Builder. A DocApp
archive is nothing but a ZIP of the included objects

precondition：
The installation options need to be set correctly for all objects that need to be archived and
installed on the target Docbase.
Be sure to include all objects in your DocApp that need to be migrated onto the target Docbase.
Remove any references to objects that have been deleted in the source Docbase while selecting a
DocApp archive.
If you have some of the objects already available on the target Docbase and you need to
incrementally update them, make sure you do not change their names (object_name property) on
the source Docbase while creating a DocApp archive.

This is extended from FM’s study note.