C4 architecture model

C4 model is used to display system architecture and explain its decomposition into elements. Diagrams of this model are organized according to the level of scaling and details:

1. C1: system context diagram

   Illustrates how the system is placed in the external context: possible user roles and other systems involved.

2. C2: container diagram

   Decomposes the system into containers (primary subsystems) and illustrates relations between them.

3. C3: component diagram

   Decomposes each container into components and illustrates internal (between components of one container) and external (with other containers) relations.

4. C4: code diagram

   Describes code elements that implement components. This level is not described in the On-Premise documentation.

To get general understanding of the On-Premise composition, C1 and C2 diagrams should be enough. If you are interested in the structure of each service, check diagrams of levels C2 (focused on separate services) and C3.

Tip

To explore a diagram in details, right-click the required image and select Open image in a new tab or Save image as.

C1: system context diagram

The following roles are expected in the On-Premise system:

• User: utilizes installed services to perform tasks.
• Engineer (DevOps): installs and maintains the system.
• Operator: manages user access to the system.

Working with data storages and public update servers is described in the lower-level diagrams.

C2: container diagram

On-Premise container is a single service or a set of APIs that implements unique functionality (for example, routing), is deployed separately, and has a set of dependencies. Different On-Premise deployments may contain different sets of containers depending on tasks that the system must resolve.

The DGCLI utility is an installation tool: it enables downloading new installation artifacts (and updating the existing ones) from the publicly hosted servers. These artifacts are then used to deploy all On-Premise services.

The diagram above illustrates all available containers and all possible relations between them without details. To "zoom in" and explore the details of which containers each service interacts with, see the diagrams below.

C2: DGCLI utility

For more information on the utility structure, see the DGCLI architecture.

C2: License service

For more information of the License service structure:

• Architecture
• Installation

C2: Maps API

For more information on the Maps API structure:

• C3 diagram (component level)
• Architecture
• Installation

C2: Search API

For more information on the Search API structure:

• C3 diagram (component level)
• Architecture
• Installation

C2: Navigation API

For more information on the Navigation API structure:

• C3 diagram (component level)
• Architecture
• Installation

C2: Urbi Pro

For more information on the Urbi Pro structure:

• C3 diagram (component level)
• Architecture
• Installation

C2: CityLens

For more information on the CityLens structure:

• C3 diagram (component level)
• Architecture
• Installation

C2: Mobile SDK

For more information on the mobile SDK structure:

• C3 diagram (component level)
• Architecture
• Installation

C2: GIS Platform

For more information on the GIS Platform structure:

• C3 diagram (component level)
• Architecture
• Installation

C2: Platform Manager

For more information on the Platform Manager structure:

• Architecture
• Installation

C3: components diagram

This section illustrates the elements that construct each container (service or API set).

C3: API Keys service

For more information on component interaction, see the Architecture of API Keys service.

C3: Maps API

For more information on component interaction, see the Architecture of Maps API.

C3: Search API

For more information on component interaction, see the Architecture of Search API.

C3: Navigation API

Navigation API has two modes of operation: standard navigation scenario and processing asynchronous requests.

Standard scenario

Navigation API processes requests to build routes that contain not more than 25 starting points and 25 ending ones. Information about traffic jams and real-time road closures can also be considered during calculation.

Processing asynchronous requests

If a requested route contains a large number of points, Distance Matrix Async API must be used for calculation.

For more information on component interaction, see the Architecture of Navigation API.

C3: Urbi Pro

For more information on component interaction, see the Architecture of Urbi Pro.

C3: CityLens

For more information on component interaction, see the Architecture of CityLens.

C3: Mobile SDK

For more information on component interaction, see the Architecture of mobile SDK.

C3: GIS Platform

For more information on component interaction, see the Architecture of GIS Platform.