Peter Maquiran
3.8 KiB
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
│ │ ├── 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.
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.