Applicazione per gestire le ore

Iniziamo l’anno con lo sviluppo di un’applicazione per gestire il log delle ore spese sui progetti dei clienti. E’ un’applicazione che utilizzerò come studio.

Quello che vorrei realizzare è un’applicazione che gestisce:

• Clienti
• Progetti
• Task
• Attività
• Dipendenti

Le tecnologie che voglio sperimentare sono:

• .net Core Api per la parte API
  • Clean Architecture
  • Redis per la cache
  • JWT per autenticazione
  • Progetto Unit
  • Connessione a mongo DB per la persistenza dei dati
  • Pipeline per la creazione artefatto e pubblicazione su github registry
• Vite js + react per la parte frontend
  • Studio architettura
  • Autenticazione
  • Ruoli
  • Pubblicazione
• K8s
  • Implementazione su Hetzner
  • Creazione repository per pubblicazione automatica
    • Dev
    • Prod

Iniziamo dalla parte che conosco meglio .net Core API.

.net Core Api architettura

Iniziamo dall’architettura dell’applicazione. Per ora vorrei seguire la cosiddetta “clean architecture”.

• src
  • Application
    • Interfaces
    • Models
    • Services
    • DTOs
    • UseCases
  • Domain
    • Entities
    • Enums
    • ValueObjects
  • Infrastructure
    • Data
      • MongoDb
      • Repositories
    • Authentication
    • Services
  • WebApi
    • Controllers
    • Filters
    • Middleware
  • Shared
    • Helpers
    • Extensions

Questa sarà la struttura del progetto. Tutte le parti possono essere poi divise in singoli progetti. Per il momento vista la bassa complessità del progetto non ha senso dividere in più progetti.

1. Application Layer

Questo strato si occupa della logica di applicazione, orchestrando la comunicazione tra il dominio e la presentazione (web API). Contiene:

• Interfaces: Definisce le interfacce che vengono implementate dai vari servizi e repository.
• Models: Contiene i modelli di dati utilizzati nell’applicazione, spesso rappresentano dati che vengono passati tra i vari strati.
• Services: I servizi contengono la logica di business che coordina la logica di applicazione. Questi servizi sono invocati dai casi d’uso.
• DTOs (Data Transfer Objects): Oggetti utilizzati per il trasferimento di dati tra i vari strati dell’applicazione (ad esempio, tra il controller e il servizio).
• UseCases: Contengono la logica specifica di ogni caso d’uso, ovvero le operazioni che il sistema deve compiere, solitamente invocano i servizi per ottenere i risultati.

2.Domain Layer

Rappresenta il cuore dell’applicazione, contenendo la logica e i concetti del dominio, come gli oggetti di valore e le entità.

• Entities: Rappresentano oggetti di dominio che possiedono un’identità unica, solitamente rappresentano le tabelle nel database.
• Enums: Definiscono valori costanti che vengono utilizzati in vari punti dell’applicazione.
• ValueObjects: Oggetti che non possiedono una propria identità, ma rappresentano concetti importanti nel dominio, come indirizzi, denaro, ecc.

3. Infrastructure Layer

Questo strato si occupa di fornire implementazioni concrete per le interfacce definite nell’Application Layer e gestire la comunicazione con sistemi esterni (database, API esterne, autenticazione, ecc.).

• Data: Contiene la logica relativa all’accesso ai dati, come i contesti del database o altre risorse persistenti.
• MongoDb: Specifica l’accesso ai dati nel database MongoDB, contenendo classi per la gestione delle operazioni CRUD.
• Repositories: Implementano la logica per l’interazione con il database e si occupano di fornire i dati alle entità o agli oggetti di valore.
• Authentication: Gestisce l’autenticazione e l’autorizzazione dell’applicazione, ad esempio, utilizzando JWT.
• Services: Contiene servizi utili per l’integrazione con altre tecnologie (come l’invio di email, servizi di pagamento, ecc.).

4. WebApi Layer

Gestisce l’interfaccia di comunicazione tra l’applicazione e il mondo esterno, esponendo API RESTful.

• Controllers: Gestiscono le richieste HTTP e invocano i casi d’uso o i servizi necessari per fornire una risposta.
• Filters: Gestiscono la logica di pre e post-processing delle richieste (ad esempio, validazioni, log, gestione degli errori).
• Middleware: Contiene la logica che deve essere eseguita su ogni richiesta HTTP, come la gestione dei permessi, l’autenticazione, ecc.

5.Shared Layer

Contiene componenti comuni e riutilizzabili che possono essere utilizzati da altri strati, come helper generici, estensioni e funzioni di supporto.

• Helpers: Funzioni ausiliarie che forniscono funzionalità comuni a più strati.
• Extensions: Estensioni di classi o metodi che aggiungono funzionalità a oggetti già esistenti in altre librerie o nel framework.

Relazioni tra i componenti

• WebApi -> Application: I controller della WebApi ricevono le richieste e invocano i casi d’uso nell’Application Layer per elaborare i dati e restituire una risposta.
• Application -> Domain: Il livello Application utilizza entità, oggetti di valore e enumerazioni definite nel Domain Layer per manipolare e restituire i dati.
• Application -> Infrastructure: I casi d’uso e i servizi dell’Application Layer si interfacciano con i repository e i servizi concreti definiti nell’Infrastructure Layer per ottenere e salvare i dati.
• Infrastructure -> MongoDb: MongoDb è una parte dell’Infrastructure Layer che gestisce l’interazione diretta con il database.
• Domain -> Infrastructure: Il Domain Layer può interagire con l’Infrastructure Layer tramite i repository, ma non dovrebbe dipendere direttamente da esso.
• Shared: Fornisce funzioni comuni a tutti i livelli, permettendo una gestione centralizzata di operazioni ripetitive e riutilizzabili.

La struttura dell’applicazione è stata creata spenderò ogni giorno due pomodori per lo sviluppo dell’applicazione. In questo spazio descriverò l’evoluzione dell’applicazione e le scelte che farò.

Un progetto software è come un viaggio, scegliamo la meta, prepariamo la valigia con i vestiti ma non sappiamo cosa succederà dall’inizio del viaggio fino all’arrivo.

Per avere meno imprevisti possibili non svilupperò l’intera applicazione ma solo due entità che hanno una relazione, Clienti e Progetti. In questo modo creerò una sorta di traccia dall’inizio alla fine e passerò il progetto ad un developer junior del mio gruppo che si occuperà di completare l’applicazione.

Buon viaggio dunque.