CRUD Design vs Event Sourcing

CRUD Design vs Event Sourcing: Una Guida per Sviluppatori

Nel panorama delle architetture software, due approcci fondamentali spesso messi a confronto sono il CRUD Design e l’Event Sourcing. Entrambi rispondono a esigenze specifiche nello sviluppo di applicazioni, ma presentano differenze sostanziali che influenzano profondamente il modo in cui i dati vengono gestiti e utilizzati.

Brevi definizioni

• CRUD Design: Un modello tradizionale per la gestione dei dati, basato su quattro operazioni fondamentali: Create, Read, Update e Delete. Ogni modifica ai dati sovrascrive lo stato precedente.
• Event Sourcing: Un modello in cui ogni modifica ai dati viene registrata come un evento immutabile in una sequenza temporale. Lo stato corrente del sistema viene ricostruito rigiocando tutti gli eventi.

CRUD e Event Sourcing: si tratta di design pattern?

Spesso ci si chiede se CRUD ed Event Sourcing rientrino nella categoria dei design pattern. In realtà:

• CRUD non è un design pattern nel senso canonico (come lo sono, ad esempio, Singleton o Observer). Piuttosto, CRUD è un acronimo che descrive le quattro operazioni principali (Create, Read, Update, Delete) tipiche di ogni sistema di persistenza dati. Viene usato come modello operativo per definire in modo semplice e immediato le interazioni con il database.
• Event Sourcing, al contrario, è considerato un pattern architetturale. Fa parte dei pattern di Enterprise Application Architecture (EAA) e si focalizza sulla gestione dello stato tramite un log di eventi immutabili. Questo approccio è descritto e formalizzato da autori come Martin Fowler ed è adottato in contesti in cui è necessario un auditing dettagliato e una scalabilità avanzata

Architettura CRUD – CRUD Design vs Event Sourcing

Descrizione

CRUD è un approccio lineare e intuitivo per gestire i dati. È largamente utilizzato nelle applicazioni basate su database relazionali, dove le entità vengono rappresentate come righe di tabelle. Ogni operazione modifica direttamente lo stato della tabella.

Esempio pratico

Un sistema di gestione utenti CRUD potrebbe avere:

• Create: Inserire un nuovo utente con nome, email e password in una tabella users.
• Read: Recuperare i dati dell’utente usando una query SQL.
• Update: Aggiornare l’email di un utente specifico.
• Delete: Rimuovere un utente dal sistema.

Esempio di query SQL:

-- Creazione utente
INSERT INTO users (name, email, password) VALUES ('Mario Rossi', 'mario@example.com', 'password123');

-- Lettura utente
SELECT * FROM users WHERE email = 'mario@example.com';

-- Aggiornamento email
UPDATE users SET email = 'mario.rossi@example.com' WHERE name = 'Mario Rossi';

-- Cancellazione utente
DELETE FROM users WHERE email = 'mario.rossi@example.com';

Vantaggi

• Semplicità: Adatto per applicazioni semplici o prototipi.
• Performance immediata: Operazioni veloci in lettura e scrittura.
• Compatibilità: Facile da integrare con ORM come Hibernate o Entity Framework.

Svantaggi

• Perdita di storico: Le modifiche sovrascrivono lo stato precedente, rendendo difficile tracciare cambiamenti.
• Scalabilità limitata: Non ideale per sistemi distribuiti o altamente scalabili.

Architettura Event Sourcing – CRUD Design vs Event Sourcing

Descrizione

L’Event Sourcing si concentra sugli eventi piuttosto che sugli stati. Ogni modifica è registrata come evento immutabile, ad esempio “Utente creato” o “Email aggiornata”. Lo stato attuale è derivato rigiocando tutti gli eventi in sequenza.

Esempio pratico

In un sistema di gestione utenti con Event Sourcing, potresti registrare eventi come:

1. Evento: UserCreated (contiene nome, email, password).
2. Evento: EmailUpdated (contiene nuova email).

Questi eventi sarebbero salvati in un log:

[
  { "event": "UserCreated", "data": { "name": "Mario Rossi", "email": "mario@example.com", "password": "password123" }, "timestamp": "2023-01-01T10:00:00Z" },
  { "event": "EmailUpdated", "data": { "email": "mario.rossi@example.com" }, "timestamp": "2023-01-02T12:00:00Z" }
]

Lo stato attuale viene ricostruito rigiocando gli eventi:

{
  "name": "Mario Rossi",
  "email": "mario.rossi@example.com",
  "password": "password123"
}

Vantaggi

• Storico completo: Ogni modifica è tracciata.
• Auditing e debugging: Puoi ricostruire lo stato a un momento specifico nel passato.
• Alta scalabilità: Ideale per sistemi distribuiti e microservizi.

Svantaggi

• Complessità: Richiede più risorse e competenze per essere implementato correttamente.
• Performance: La ricostruzione dello stato dagli eventi può essere onerosa.
• Gestione dello storage: Il log degli eventi può crescere rapidamente.

Confronto: CRUD Design vs Event Sourcing

Differenze chiave – CRUD Design vs Event Sourcing

Quando usare CRUD

• Applicazioni CRUD sono ideali per sistemi semplici, dove la velocità di sviluppo e la gestione diretta dei dati sono prioritari, ad esempio:
  • Gestione di anagrafiche utenti.
  • App di e-commerce con volumi di dati limitati.

Quando usare Event Sourcing

• Scegli Event Sourcing per sistemi complessi e distribuiti, dove è cruciale mantenere uno storico completo degli eventi, ad esempio:
  • Sistemi finanziari (registrazione di transazioni).
  • Applicazioni IoT con tracciamento in tempo reale.
  • Sistemi di gestione ordini per e-commerce globali.

Conclusione: CRUD Design vs Event Sourcing

CRUD e Event Sourcing non sono in competizione diretta, ma servono scopi diversi. Per scegliere il modello giusto, valuta attentamente i requisiti del tuo progetto: semplicità e velocità o tracciabilità e scalabilità. Entrambi gli approcci hanno il loro posto nel toolkit di uno sviluppatore moderno.

(fonte) (fonte)

Innovaformazione, scuola informatica specialistica promuove la cultura dello sviluppo software e la formazione continua per i team di sviluppatori delle aziende. Trovate l’offerta formativa a catalogo sul nostro sito QUI.

Per altri articoli tecnici invece consigliamo di navigare sul nostro blog QUI.

INFO: info@innovaformazione.net – Tel. 3471012275 (Dario Carrassi)