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
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:
C2: Maps API
For more information on the Maps API structure:
C2: Search API
For more information on the Search API structure:
C2: Navigation API
For more information on the Navigation API structure:
C2: Urbi Pro
For more information on the Urbi Pro structure:
C2: CityLens
For more information on the CityLens structure:
C2: GIS Platform
For more information on the GIS Platform structure:
C2: Platform Manager
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
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: GIS Platform
For more information on component interaction, see the Architecture of GIS Platform.