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

Components

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

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
│ │ ├── attachment
│ │ │ ├── entity
│ │ │ ├── repository
│ │ │ └── use-cases
│ ├── components
│ │ ├── gabinete
│ │ │ ├── domain
│ │ │ ├── data
│ │ ├── Agenda
│ │ │ ├── domain
│ │ │ ├── data
│ ├── UI
│ │ ├── pages
│ │ │ ├── share
| │ │ │ ├── buttons
│ │ │ │ └── modal
│ │ │ ├── Home
│ │ │ | ├── service
│ │ │ │ └── store
│ │ │ ├── Agenda
│ │ │ ├── Gabinete
│ │ │ ├── Actions
│ │ │ ├── Chat
│ ├── infra
│ │ ├── http
│ ├── 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.

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.

3.9 KiB Raw Blame History