# Vision Document

<figure><img src="https://869823119-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpyWVnmtszkUSqMcP8ips%2Fuploads%2FGnbtoW7WAn4Zo7AIqUZK%2Fpngtree-vision-symbol-sign-in-simple-style-on-a-white-background-png-image_4863964.png?alt=media&#x26;token=77f2bafb-89a2-44e5-934c-f3ea0869aac2" alt="" width="90"><figcaption></figcaption></figure>

### Table of Contents

* **Summary** - Page 1
* **Introduction** - Page 2
* **Problem Description** - Page 2
* **Descriptions of Stakeholders and Users** - Page 2
  * User Summary - Page 2
* **Product Overview** - Page 3
  * Product Perspective - Page 3
  * Assumptions and Dependencies - Page 3
  * Main Product Capabilities/Requirements - Page 4
  * Main Non-Functional Requirements (NFR) of the Product - Page 5
  * Chosen Technology Stack - Page 5
  * Proposal Development Phases - Page 6

***

### Introduction

This document aims to collect, analyze, and define high-level system needs and resources. It focuses on the necessary resources for involved users and the reasons behind these needs. Details on how the system satisfies these needs will be described in the use case and supplementary specifications.

The 9line Spaces system is a space booking platform that allows users to schedule the use of spaces (such as pools, party halls, etc.) on specific dates and times, implementing a clean architecture (Clean Architecture) with Domain Driven Design (DDD).

***

### Problem Description

The current space booking process is entirely manual, relying on traditional methods such as phone calls, emails, and physical calendars. This approach demands significant effort and repetitive work from space owners and users. New bookings are created manually each time, but there are no clear strategies for storing and retrieving saved information, leading to a higher possibility of errors during the booking process, double bookings, and lack of centralized management.

The absence of a digital platform results in:

* Difficulty in managing multiple spaces
* Lack of real-time availability information
* Manual scheduling conflicts
* No automated notifications
* Limited user experience
* Difficulty in tracking and analyzing usage patterns

***

### Descriptions of Stakeholders and Users

This section provides a profile of the main users involved in the project and the key problems the proposed solution aims to address. It does not detail specific user requests or requirements, as those are captured in separate stakeholder request artifacts. Instead, it provides the foundation and justification for why the requirements are necessary.

#### User Summary

| Name              | Description                                                       | Responsibilities                                                                                                                              |
| ----------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Administrator** | User with the highest degree of permission within the system.     | <p>- Manage users<br>- Manage all spaces<br>- Monitor system performance<br>- Configure system settings<br>- Manage roles and permissions</p> |
| **Manager**       | User responsible for managing specific spaces and their bookings. | <p>- Manage spaces<br>- Approve/reject appointments<br>- Manage space information<br>- View space analytics<br>- Handle user inquiries</p>    |
| **User**          | End user who books spaces for personal or business use.           | <p>- Browse available spaces<br>- Make appointments<br>- Rate spaces<br>- Manage personal bookings<br>- Receive notifications</p>             |

***

### Product Overview

This section provides a high-level view of the product's features, exposing its main capabilities, interfaces with other systems, and configurations.

The image below demonstrates, at a high level of abstraction, the proposed solution's architecture including the system's main components.

#### Image 1 - Overview

```
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Web Client    │    │   Mobile App    │    │   Admin Panel   │
│   (React/Next)  │    │   (React Native)│    │   (Next.js)     │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                    ┌─────────────────┐
                    │   API Gateway   │
                    │   (Express.js)  │
                    └─────────────────┘
                                 │
                    ┌─────────────────┐
                    │   Core Modules  │
                    │   - Users       │
                    │   - Spaces      │
                    │   - Appointments│
                    │   - Ratings     │
                    │   - RBAC        │
                    │   - Notifications│
                    └─────────────────┘
                                 │
         ┌───────────────────────┼───────────────────────┐
         │                       │                       │
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   PostgreSQL    │    │     Redis       │    │   External      │
│   Database      │    │     Cache       │    │   Services      │
└─────────────────┘    └─────────────────┘    └─────────────────┘
```

#### Product Perspective

The proposed solution aims to automate the space booking and management process, including all tasks and subtasks related to space scheduling. The solution's objective is to maximize the replacement of manual work and automate repetitive tasks, integrating all functionalities into a single tool and allowing access through network communication.

End-users will access the system's functionalities through a browser or mobile application, without needing to install any software on their machine. The system provides a seamless experience across multiple platforms.

#### Assumptions and Dependencies

The proposed solution considers the existence of an infrastructure capable of accommodating the developed system, which can be a proprietary infrastructure or use cloud deployment platforms.

Regarding the client application, its only dependency will be internet access, as without it, interaction between the client application and the rest of the system will not be possible.

The system depends on external services for:

* Email notifications (SMTP services)
* SMS notifications (SMS gateway services)
* Push notifications (Firebase/APNS)
* Payment processing (if applicable)
* Maps and geolocation services

***

### Main Product Capabilities/Requirements

The correct communication with external services (specifically notification services) is essential for the development of the respective functionality. The existence of interfaces for this communication is essential for the development of the respective functionality.

The main functionalities necessary for the proposed solution are listed below:

#### FT 01 - User Authentication/Authorization

Only duly authorized users should be able to access the functionalities provided by the system. The system implements JWT-based authentication with role-based access control.

#### FT 02 - Manage Users

The system provides user management functionalities (create, alter, exclude users) and the ability to personalize different access levels for each user. The system supports three main user types: Administrator, Manager, and User.

#### FT 03 - Manage Spaces

The functionality to manage all types of spaces (pools, party halls, meeting rooms, etc.), allowing searches, alterations, and removals. Each space includes detailed information such as photos, rules, amenities, and location.

#### FT 04 - Manage Appointments

The functionality to manage all types of appointments, allowing users to book spaces for specific dates and times. The system includes conflict detection, approval workflows, and change management.

#### FT 05 - Data Visualization

The functionality to visualize the booking status over different temporal moments (daily, monthly, annual), presenting space usage, revenue, and total values.

#### FT 06 - Scenario Projection

The functionality to create different scenarios based on space availability and booking patterns, helping managers optimize space utilization.

#### FT 07 - Manage Bank Accounts

The functionality to control all bank accounts and their configurations related to payment processing and financial management.

#### FT 08 - Manage Investments

The functionality to register and control investments related to space improvements and maintenance, and to visualize them over different temporal moments.

#### FT 09 - Manage Events

The functionality to register and control expenses originating from realized and scheduled events, and to visualize them over different temporal moments.

***

### Main Non-Functional Requirements (NFR) of the Product

#### Performance Requirements

* **Response Time**: API endpoints must respond within 200ms for 95% of requests
* **Throughput**: System must handle 1000 concurrent users
* **Availability**: 99.9% uptime requirement
* **Scalability**: Horizontal scaling capability

#### Security Requirements

* **Authentication**: JWT-based authentication with refresh tokens
* **Authorization**: Role-based access control (RBAC)
* **Data Protection**: Encryption at rest and in transit
* **Input Validation**: Comprehensive input validation and sanitization

#### Reliability Requirements

* **Error Handling**: Graceful error handling with meaningful messages
* **Logging**: Structured logging for monitoring and debugging
* **Health Checks**: Comprehensive health check endpoints
* **Graceful Shutdown**: Proper cleanup of resources

#### Usability Requirements

* **Responsive Design**: Support for desktop, tablet, and mobile devices
* **Accessibility**: WCAG 2.1 AA compliance
* **Internationalization**: Support for multiple languages
* **User Experience**: Intuitive and user-friendly interface

#### Maintainability Requirements

* **Code Quality**: Clean architecture with domain-driven design
* **Testing**: Comprehensive test coverage (unit, integration, e2e)
* **Documentation**: Complete API documentation with Swagger
* **Monitoring**: Application performance monitoring and alerting

***

### Chosen Technology Stack

#### Backend

* **Runtime**: Node.js (v18+)
* **Framework**: Express.js
* **Database**: PostgreSQL with Prisma ORM
* **Cache**: Redis
* **Authentication**: JWT
* **Testing**: Vitest
* **Logging**: Winston
* **Validation**: Zod

#### Frontend

* **Web Application**: Next.js with React
* **Mobile Application**: React Native
* **Styling**: Tailwind CSS
* **State Management**: Zustand/Redux
* **Testing**: Jest and React Testing Library

#### Infrastructure

* **Containerization**: Docker
* **Orchestration**: Docker Compose
* **CI/CD**: GitHub Actions
* **Monitoring**: Application performance monitoring
* **Documentation**: Swagger/OpenAPI

#### External Services

* **Email**: SMTP services (SendGrid, AWS SES)
* **SMS**: SMS gateway services
* **Push Notifications**: Firebase Cloud Messaging
* **Maps**: Google Maps API
* **Payment**: Stripe (if applicable)

***

### Proposal Development Phases

#### Phase 1: Foundation (Weeks 1-4)

* **Week 1-2**: Project setup and architecture definition
* **Week 3-4**: Core infrastructure and database design
* **Deliverables**: Project structure, database schema, basic API setup

#### Phase 2: Core Features (Weeks 5-12)

* **Week 5-6**: User authentication and authorization
* **Week 7-8**: Space management functionality
* **Week 9-10**: Appointment booking system
* **Week 11-12**: Rating and review system
* **Deliverables**: Core API endpoints, basic frontend, authentication system

#### Phase 3: Advanced Features (Weeks 13-20)

* **Week 13-14**: RBAC system implementation
* **Week 15-16**: Notification system
* **Week 17-18**: Data visualization and analytics
* **Week 19-20**: Mobile application development
* **Deliverables**: Complete backend, web application, mobile app

#### Phase 4: Testing and Deployment (Weeks 21-24)

* **Week 21-22**: Comprehensive testing and bug fixes
* **Week 23-24**: Production deployment and monitoring setup
* **Deliverables**: Production-ready system, monitoring, documentation

#### Phase 5: Optimization and Enhancement (Weeks 25-28)

* **Week 25-26**: Performance optimization
* **Week 27-28**: Additional features and improvements
* **Deliverables**: Optimized system, additional features, user feedback integration

***

**Version**: 1.0.0\
**Last Update**: July 2025\
**Author**: Antonio Silva\
**Email**: <contato@antoniobsilva.com.br>
