Skip to content

Commit

Permalink
chore: use shared slides
Browse files Browse the repository at this point in the history
  • Loading branch information
kelvin-olaiya committed Oct 1, 2024
1 parent e04520b commit 7a36150
Showing 1 changed file with 10 additions and 83 deletions.
93 changes: 10 additions & 83 deletions content/_generator.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,19 +15,7 @@ aliases = [

---

# Introduction

**Revue** is a distributed real-time system for video surveillance. It allows the user to:

1. Check an environment remotely through cameras

2. Monitor an environment using sensors

3. Add security rules based on his needs triggering alarms
1. Intrusions in case of violated safety rule by cameras
2. Outliers in case of violated safety rule by sensors

Due to his level of configurability, Revue can be used in multiple scenarios.
{{% import path="shared-slides/introduction.md" %}}

---

Expand Down Expand Up @@ -65,76 +53,27 @@ System's main properties:

---

## Event Storming

In order to create a better understanding of the domain, we used the Event Storming technique. We performed the following steps:

1. **Unstructured exploration**: the goal is to identify the main events
2. **Timeline**: the events are ordered in time
3. **Pivotal events & pain points**: discussion about critical point that require attention and reasoning on events that have impact on the domain.
4. **Actors, Commands, Policies and Read Models**
5. **Aggregates**: groping of event into aggregates
6. **Bounded contexts**: identification of bounded contexts based on aggregates interaction

[Documentation](https://revue-org.github.io/revue/docs/report/design/event-storming)
{{% import path="shared-slides/design/event_storming.md" %}}

---

## Bounded Contexts

After the event storming session, the following contexts have been identified:

- **Auth**: Responsible for managing the authentication and authorization of the users. It also is responsible for managing the permissions of the users.
- **User**: This context is responsible for managing the users of the system, in particular, nothing regarding the authentication process but only the management of the user registry.
- **Monitoring**: It is responsible for managing the devices and the data they produce. This context is responsible for consulting the data produced by the devices, their configurations and everything regarding the WoT interactions.
- **Alarm**: Responsible for managing the alarms in the overall system. It is also responsible for the object recognition feature of the system.
- **Notification**: Responsible for managing the notifications of the system. It is responsible for sending notifications to the users when particular events occur.
- **Location**: Responsible for the location management of the system.
{{% import path="shared-slides/design/bounded_context.md" %}}

---

## Context Map

![Context Map](https://raw.githubusercontent.com/revue-org/revue/main/docs/website/docs/report/img/ContextMap.png)
{{% import path="shared-slides/design/context_map.md" %}}

---

# Architecture

We chose to use a microservices architecture for the system. This architecture consists on designing software applications as suites of independently deployable services. Each service runs in its own process and communicates with other services through a well-defined interface.

- [Components & connectors view](https://revue-org.github.io/revue/docs/report/design/architecture/documentation#components--connectors)
- [Module view](https://revue-org.github.io/revue/docs/report/design/architecture/documentation#module-view)
- [Deployment view](https://revue-org.github.io/revue/docs/report/design/architecture/documentation#deployment-view)
{{% import path="shared-slides/architecture/architecture.md" %}}

---

## Microservices

Using the _Bounded Contexts Decomposition Strategy_, we identified the following microservices:

- **Auth Service**: Responsible for managing the authentication and authorization of the users.
- **User Service**: Responsible for managing the users of the system.
- **Device Service**: Responsible for managing the devices connected to the system.
- **Monitoring Service**: Responsible for managing the data produced by the devices.
- **Alarm Service**: Responsible for managing security rules and anomalies detections.
- **Recognition Service**: Responsible for performing object recognition on cameras video streams.
- **Notification Service**: Responsible for managing the notifications of the system.
- **Location Service**: Responsible for the location management of the system.
- **Log Service**: Responsible for storing events that occur in the system.
{{% import path="shared-slides/architecture/microservices.md" %}}

---

## Clean Architecture

The design of all relevant microservices follows the Clean Architecture pattern. This helped us in maintaining a core domain design that abstracts away from all technical issues. As showed in the picture above, we made use of the following layers:

- **Domain**: DDD entities, value objects, factories, ...
- **Application**: DDD services, repositories, ...
- **Presentation**: Machinery to translate external data representation to domain entities and vice versa.
- **Infrastructure**: Mostly external service implementation, DB interfaces, REST APIs, Events managers, ...

[Documentation](https://revue-org.github.io/revue/docs/report/design/architecture/microservices#clean-architecture)
{{% import path="shared-slides/architecture/clean_architecture.md" %}}

---

Expand All @@ -158,27 +97,15 @@ We reasoned about:

---

# Deployment

Two way to deploy the system:

1. **Docker Compose**: for local development and testing
2. **Kubernetes**: for production

[Documentation](https://revue-org.github.io/revue/docs/category/deployment)
{{% import path="shared-slides/deployment/deployment.md" %}}

---

## Kubernetes

- Configuration files for Kubernetes and `deploy` script are available in the repository [revue-kubernetes](https://github.com/revue-org/revue-kubernetes/)
- It is provided an example of how to deploy the system on a Raspberry Pi cluster, using the _k3s_ distribution.
{{% import path="shared-slides/deployment/kubernetes.md" %}}

---

### Cluster Overview

![Kubernetes deployment](https://raw.githubusercontent.com/revue-org/revue/main/docs/website/docs/report/img/kubernetes-deployment.png)
{{% import path="shared-slides/deployment/cluster_overview.md" %}}

---

Expand Down

0 comments on commit 7a36150

Please sign in to comment.