# Software Architecture documentation 
This Architecture promotes a clear separation of concerns by dividing the system into layers, each with its own responsibility. However, rather than using a traditional layered approach, we'll focus on a component-based structure where each component adheres to SOLID principles and can operate independently. The architecture  consist of the following layers:

- **Components**: Business components
- **Presentation**: UI components and Angular services.

## Architecture Layers

![Alt text](./svg/aa.svg)

### Components

![Alt text](./svg/business-co.svg)

Components are the core business logic units in the application. The components are divided into two sub-layers:

**Domain Layer**

- Contains business logic and rules.
- Models the business entities.
- Does not depend on the data layer or any other external services.
  
**Data Layer**

- Responsible for data access and persistence.
- Contains repositories or data services that interact with APIs or databases.
- Isolated from the domain layer to ensure a clear separation of concerns.

###  Presentation
![Alt text](./svg/ui-layer.svg)

The presentation layer is responsible for the user interface and interactions. It consists of Angular UI components and services:


## File Structure Explanation
The project is divided into several key sections, each serving a specific purpose:

**Source Code (src)**

- **common**: Shared utilities such as decorators, interceptors, and guards.

-  **core**: Business Object divided by features to store shared entity, use case and repository interface

-  **infra**: Infrastructure code such as storage, HTTP clients, logging, camera, and file system.

-  **libs**: Reusable libraries (e.g., session management, cryptography).

-  **components**: Business Feature divided by responsibility 

-  **UI**: Presentation layer with Angular divided by Feature 

-  **utils**: Utility functions and constants.


├── package-lock.json
├── package.json
├── src
│   ├── common
│   ├── core
│   │   ├── chat
│   │   │   ├── entity
│   │   │   ├── repository
│   │   │   └── use-cases  
│   ├── module
│   │   ├── agenda
│   │   │   ├── domain
│   │   │   ├── data
│   │   ├── chat
│   │   │   ├── domain
│   │   │   ├── data
│   ├── UI
│   │   ├── pages
│   │   │   ├── share
|   │   │   │   ├── buttons
│   │   │   │   └── modal
│   │   │   ├── Home   
│   │   │   |   ├── service
│   │   │   │   └── store
│   │   │   ├── Agenda
│   │   │   ├── Chat
│   ├── infra
│   │   ├── http  
│   │   ├── socket  
│   │   ├── database
│   │   ├── camera
│   ├── utils
│   │   ├── date.ts
│   │   ├── exception.ts
│   │   ├── sort.ts
│   ├── libs


## Achieving Reusability



### Example: Gabinete Page

Consider a Gabinete scenario:        
- **Business components**: Event Component, Gabinete Component     
- **UI components**: Gabinete UI Business

In this setup, the Event Component functionalities are reusable without any dependency on UI details. If the product team introduces create-event functionality in the Gabinete screen, the Event Component module can be added as a dependency to the Gabinete UI module seamlessly.
![Alt text](./svg/aa-relationship.svg)

## Conclusion
This file structure supports Clean Architecture by ensuring a clear separation of concerns and adhering to SOLID principles. Each part of the application is modular, making it easy to maintain, test, and extend. This setup promotes a clean and organized project that scales well as complexity grows.