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:
-
Illustrates how the system is placed in the external context: possible user roles and other systems involved.
-
Decomposes the system into containers (primary subsystems) and illustrates relations between them.
-
Decomposes each container into components and illustrates internal (between components of one container) and external (with other containers) relations.
-
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
![C1: system context diagram](/img/c4/c1.png)
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
![C2: container diagram](/img/c4/c2-all.png)
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
![C2: focus on DGCLI](/img/c4/c2-dgcli.png)
For more information on the utility structure, see the DGCLI architecture.
C2: License service
![C2: focus on license service](/img/c4/c2-license.png)
For more information of the License service structure:
C2: Maps API
![C2: focus on Maps API](/img/c4/c2-maps.png)
For more information on the Maps API structure:
C2: Search API
![C2: focus on Search API](/img/c4/c2-search.png)
For more information on the Search API structure:
C2: Navigation API
![C2: focus on Navigation API](/img/c4/c2-navi.png)
For more information on the Navigation API structure:
C2: Urbi Pro
![C2: focus on Urbi Pro](/img/c4/c2-pro.png)
For more information on the Urbi Pro structure:
C2: CityLens
![C2: focus on CityLens](/img/c4/c2-citylens.png)
For more information on the CityLens structure:
C2: Mobile SDK
![C2: focus on the mobile SDK](/img/c4/c2-mobile-sdk.png)
For more information on the mobile SDK structure:
C2: GIS Platform
![C2: focus on GIS Platform](/img/c4/c2-gis-platform.png)
For more information on the GIS Platform structure:
C2: Platform Manager
![C2: focus on Platform Manager](/img/c4/c2-platform-manager.png)
For more information on the Platform Manager structure:
C3: components diagram
This section illustrates the elements that construct each container (service or API set).
C3: API Keys service
![C3: diagram of API Keys service components](/img/c4/c3-keys.png)
For more information on component interaction, see the Architecture of API Keys service.
C3: Maps API
![C3: diagram of Maps API components](/img/c4/c3-maps.png)
For more information on component interaction, see the Architecture of Maps API.
C3: Search API
![C3: diagram of Search API components](/img/c4/c3-search.png)
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.
![C3: diagram of Navigation API components](/img/c4/c3-navi.png)
Processing asynchronous requests
If a requested route contains a large number of points, Distance Matrix Async API must be used for calculation.
![C3: diagram of Navigation API components used for processing asynchronous requests](/img/c4/c3-navi-async.png)
For more information on component interaction, see the Architecture of Navigation API.
C3: Urbi Pro
![C3: diagram of Urbi Pro components](/img/c4/c3-pro.png)
For more information on component interaction, see the Architecture of Urbi Pro.
C3: CityLens
![C3: diagram of CityLens components](/img/c4/c3-citylens.png)
For more information on component interaction, see the Architecture of CityLens.
C3: Mobile SDK
![C3: diagram of mobile SDK components](/img/c4/с3-mobile-sdk.png)
For more information on component interaction, see the Architecture of mobile SDK.
C3: GIS Platform
![C3: diagram of GIS Platform components](/img/c4/c3-gis-platform.png)
For more information on component interaction, see the Architecture of GIS Platform.