Introduction
This autogenerated website stores all the relevant artifacts produced to document the process of designing the system following a Domain Driven approach as well as the final architecture of the solution.
Project Proposal
Members
- Thomas Angelini: thomas.angelini@studio.unibo.it
- Luca Deluigi: luca.deluigi3@studio.unibo.it
- Simone Magnani: simone.magnani4@studio.unibo.it
Scenario
The group wants to develop an instant messaging application. In this system a user could search for another user and start to communicate with them by creating a chat together. The goal is to let users communicate with each other by sending messages in chats, delivered in real-time.
Course requirements
Engineering a scalable, full-fledged, clean, high quality, mantainable microservices system for instant messaging with event oriented communication, real time client-server communication and distrubuted issues aknowledgment and addressing.
Domain Exploration ↵
Knowledge Crunching
The process of knowledge crunching involves stakeholder and domain experts (the team itself took these roles) and creates (iteratively) a refined Ubiquitous Language, Context Map and Domain Model through the dialogue and the collection of User stories (not reported here) and Use Cases.
Note
The following documentation regards the analysis of a simplified Problem Space in order to focus (for the purposes of this project) to the technology know-how of scalable, full-fledged microservices systems based on DDD patterns and effective distributed systems design principles.
Use Cases
There is only one type of user for our service. A user owns an account and is able to manage personal information and login data for it. With an account, it's possible to search for other users and create a chat with them. In a chat it's possible to send messages to other users. Once a user has sent a message, he can edit or delete it. The system currently provides
Ubiquitous Language
| Term | Definition | Usage | Other meanings |
|---|---|---|---|
| Message | Piece of information sent in a chat by a user relative to a specific moment. | As a noun or as a verb. To message means to send a message. | |
| Chat | Entity that contains messages and other metadata. A chat can involve at least one user. | As a noun. As a verb it means to send and/or receive messages. | The container of related messages. The communication medium between users. |
| Account | A collection of personal information about a user that enables chat related functionalities. | As a noun, related to creation, deletion, update, personal information, authentication and authorization features. | |
| User | A person with an account in the service. | As a noun, related to manage chat and personal information. | |
| Send | To deliver a message in a chat, where some users can see it in real time or later. | As a verb, relative to messages. | The act of requesting the service to deliver a message to its destination. |
| Search | To search a user in the system, to start a converstion with him. | As a verb, relative to users. | The act of requesting the service to search a user. |
| Private Chat | Chat that involves only two users, a creator and a partecipant. | ||
| Private Message | Message sent in a private chat. It contains additional information than normal message. |
Ended: Domain Exploration
Domain Analysis ↵
Bounded contexts
Microchat has two subdomains: * User: subdomain contains the use cases for which the user is involved and it's the main focus. * Chat: subdomain that includes the relationships between user and chat, and all the use cases wher instanti messaging and chats are the main focus.
User subdomain
Supporting subdomain
Auth context
Responsible for keeping login data, managing authentication for the entire system.
User context
Responsible for keeping personal information unrelated from authentication, like name or surname. Provides endpoints to search for users with keywords.
Chat subdomain
Core subdomain
Private Chat context
Manages personal communication between users, with chats and messages.
Context Map
Legend
Microchat context map
Domain Models ↵
User Subdomain Model
User context
Details
Name and Surname
constraints:
- \(value\) must have almost 4 letters.
- \(value\) can't have more than 100 letters.
Username
constraints:
- \(value\) must have almost 4 letters.
- \(value\) matches
^[A-Za-z][A-Za-z0-9]*(_[A-Za-z0-9]{2,}){0,3}$
Auth context
Details
Username
constraints:
- \(value\) must have almost 4 letters.
- \(value\) matches
^[A-Za-z][A-Za-z0-9]*(_[A-Za-z0-9]{2,}){0,3}$
constraints:
- \(value\) must respect regex for email.
Password Hash
constraints:
- \(password\) must not be empty.
- \(password\) must have almost 8 characters.
Domain Events
- Account Registered: emitted when an account is registered to the system.
- Account Unregistered: emitted when an account is removed from the system.
Chat Domain Model
Private Chat context class diagram
Details
MessageText
constraints:
- \(text.length < 4000\).
Chat constraints
- Chat can't be deleted.
- PrivateChat can have only two partecipants, a owner and a partecipant.
- A User can interact with a Chat only if it is a participant.
- A User can send messages within a Chat only if it is a participant.
- A User can only delete messages in a Chat if it's the original sender.
Domain Events
- Chat created: emitted when a chat is registered to the system.
- Chat Deleted: emitted when a chat is removed from the system.
Ended: Domain Models
Ended: Domain Analysis
Architecture ↵
Architecture Components
Communication Diagram
Sequence Diagrams
Command
New user
Send message
Send message with multiple chat replicas
