Skip to main content

Detailed Design

Session Microservice​

The Session microservice is responsible for managing Youtube streaming sessions. The application synchronizes the video of all the users connected to a session, in response to play/stop/timeline moves actions.

It also maintains up-to-date a session chat, through which users can communicate with each other during the streaming.

Project structure​

packages

The Session microservice follows the Clean architecture pattern to maintain separate code responsibilities and enhance software modularity. The business logic is placed in the domain layer, inside the aggregates previously identified, while the communication is captured by the infrastructure layer.

The application layer acts as a middleware between the infrastructure and domain layer.

Design​

The software moves around the concepts of Commands, Domain events, and Reactions.

Commands​

Commands involve actions performed by the users. Whenever a message is received by the microservice, such as CreateSession, a new Command is generated by the infrastructure layer.

The latter in turn sends them to the application layer, which is responsible for validating them, and eventually emits new Domain Events. The possible Commands are:

  • UserToken: the user sends the token to start communicating with the microservice;
  • CreateSession: the user wants to create a new session, by providing a URL;
  • JoinSession: the user wants to join an already existing session, by providing the session name;
  • LeaveSession: the user wants to leave a previously joined session;
  • SendMessage: the user wants to send a message in the chat;
  • PlayVideo: the user wants to play the session video. It should provide the timestamp where to start playing it;
  • StopVideo: the user wants to stop the session video. It should provide the timestamp where to stop it.

Commands

Command handlers are defined in the application layer through an ISessionService interface:

service

Domain events​

Domain events are emitted by the application layer whenever a Command is validated and they represent a mechanism through which the domain aggregates are informed of user actions. In particular:

  • Whenever a CreateSession Command is accepted, SessionService adds a new Session aggregate to its local Session Repository;
  • An Event Bus is passed as a parameter to this new Session, through which it can listen to new Domain events;
  • Each command has a respective Domain event, except UserTokenCommand which is used for communication purposes. This means that if a Command is validated by the SessionService, the respective Session aggregate is informed and can react according to that event.
Aggregates

Events

Reactions​

As previously mentioned, the communication part of the application should be constrained inside the infrastructure layer. As such, the User domain model shouldn't contain the physical references of the Users. This approach leads us to decouple the Session definition inside the domain layer, with the one inside the infrastructure, which for example should add/remove User references whenever a join/disconnection is validated by the business logic.

This decoupling is achieved by the use of Reactions. This mechanism allows the infrastructure layer to pass a set of functions that the business logic can call whenever a Domain event is emitted.

In particular, the following Reaction implementations should be embedded inside the User Commands:

  • ISessionReactions: used by the aggregates to add/remove User physical references inside the infrastructure's session;
  • IChatReactions: used to send Text or Notification Messages to a specific User o to the entire Session;
  • IVideoReactions: to retrieve the Video State of the User, to synchronize either it or the entire Session.

Reactions

Authentication Microservice​

The Authentication microservice is responsible for managing the authentication of the users. The application provides a REST API to register and authenticate users. It also manages the token validation and refresh.

Project structure​

auth packages

The Authentication microservice follows the Clean architecture pattern to maintain separate code responsibilities and enhance software modularity. The business logic is placed in the domain layer, inside the aggregates previously identified, while the communication is captured by the infrastructure layer.

In particular:

  • The application layer acts as a middleware between the infrastructure and domain layer;
  • The infrastructure layer is responsible for the communication with the database and the JWT token generation;
  • The domain layer is responsible for the business logic;
  • The presentation layer is responsible for the REST API.

Auth-Classes

Design​

The software needs to manage the authentication of the users. The possible actions are:

  • Register: the user wants to register to the system;
  • Login: the user wants to log in to the system;
  • Logout: the user wants to log out of the system.

Some additional actions are:

  • ValidateToken: to validate the token;
  • RefreshToken: to refresh the token;
  • GetData: to get the user’s data given the token.

Profile Microservice​

The Profile microservice is responsible for managing the profile of the users. The application provides a REST API to get and update the profile of the users.

The Profile service is also based on the Clean architecture pattern and follows the same structure as the Authentication service.

Profile-Classes

Design​

The software needs to manage the profile of the users. The possible actions are:

  • GetProfile: the user wants to get the profile;
  • UpdateProfile: the user wants to update the profile;

Other actions are:

  • CreateProfile: to create the profile;
  • AddVideo: to add a watched video to the profile.