Skip to content

Latest commit

 

History

History
80 lines (51 loc) · 3.52 KB

trento-architecture.md

File metadata and controls

80 lines (51 loc) · 3.52 KB
Raw

Trento Architecture

Here's a high level view of what we do to achieve the result of providing a reactive event driven system.

Trento Architecture

  • Discovery
  • Scenario Detection
  • Business rules validation
  • Events & State change
  • State propagation & Reaction

Discovery

Trento Agent extracts relevant information on the target infrastructure and publishes those to the control plane.
(cluster discoveries, host discoveries, cloud discoveries...)

The control plane Discovery integration securely accepts published discoveries, stores them and triggers Scenario Detection.

Scenario Detection

The control plane discovery integration leverages specific policies to determine the scenario to be triggered based on the discovered information.

That means we need to be able to determine which command to dispatch in the application. (RegisterHost, RegisterDatabaseInstance and so forth...)

Business rule validation

The detected scenario dispatches the needed command(s) which trigger validation of the requested action(s) against the current state and the proper business rules for the usecase.

Events & State change

Going through the previous steps of dispatching and action in the system and applying business rules to the process, translates in things actually happening (or not) and changing some state (or not).

When things happen we represent them as events (SAPSystemHealthChanged, ChecksExecutioncompleted), we store them in an append only Event Store and use them as the source of truth of the system (or part of it).

See Event Sourcing here

State Propagation & Reaction

Once things happen the system notifies the world about it by emitting the recorded events so that interested components can listen for those and react accordingly.

Reaction may be any orthogonal listener responsible to deliver part of the feature being served.

Some of possible reactions

  • projecting read optimized models for specific usecases (Clusters, Hosts, Heartbeats) maybe later served via APIs
  • Sending and email whenever a SAP System's health goes critical
  • Broadcasting changes to the Reactive UI via websockets
  • Third party software integration
  • ...

Not only discovery

Notice how this document started with Discovery triggering actions and subsequent events in the system.

That's not the only case indeed.

The user can trigger actions via the Reactive web UI and so the Scenario-Business Rules-Events-Reaction flow is the same, clearly without the Discovery. Actions (or commands) may also be triggered via API integration, cli integration, Messaging or any other means.

This is possible thanks to an hexagonal approach to the architecture.

Bonus point

We referred to Event Sourcing and you may have noticed some parallelisms with CQRS.

That's it.

We approached architecture and development with Agile mindset and Domain Driven Design approach to properly understand the problem space and provide good solutions by leveraging ES, CQRS and Reactivity.

In order to avoid accidental complexity we don't use ES+CQRS everywhere by default. Whenever possible we use simpler implementations for non-critical aspects. (Tagging for instance, is a basic CRUD operation)

There's a lot of literature out there, here's just a perspective of the thing.

ES+CQRS