High-Level Architecture View
In the main pane of the analysis page we see the various services visualized as spheres.
The size of the sphere is proportional to the number of flows that go through it, and the color represents the exclusivity of the resources (low - red, medium - blue and high - green).
Resources are data sources or communication channels the services read and write to, such as HTTP/HTTPS sockets, SQL database, MongoDB, Redis, Kafka, etc.
An exclusive resource is a resource that is used just by one service and a non-exclusive resource is a resource accessed from multiple services.
Resource exclusivity is the ratio (percentage) between the exclusive and non-exclusive resources. Services with resource exclusivity of 66% and above are green, between 33%-66% are blue and below 33% are red.
The dashed arrows across services represent calls between services. Hovering over these lines lists the calls.
Add the service names and tech stacks icons by clicking Service Labels and Tech Stack in the Filters section on the left pane
All the services are marked Java except oms-trucking which is marked as Node.js
The layout of the spheres represents architectural layers based on the dependencies between the services. We see that oms-product is at the topmost layer since no service is calling it, but it calls two other services that in turn call other services. The mailsender and oms-order services are at the bottom layer as they don’t call other services. You can move the spheres to convey a different layering. For example, you can place the oms-order at the top layer by moving it to the top of the graph. Clicking Reset Graph on the left pane will restore the layout to its original state.
Clicking on spheres also selects them in the Services list in the right pane: the details of the service are shown under Services in the right pane, and the service also appears under Selected Services in that pane. You can also select services in the list of services on the right pane.
Hovering over a sphere shows a … icon. Clicking on it opens the Service Details dialog where you can rename the service, add textual notes about it and assign it with Tags (new or existing). Using tags enables creating and enforcing architectural rules, for example, you can assign services with a tag Client and services with a tag Server and have a rule that a Client cannot make a call to a Server (rules will be discussed later in this workshop).