In Domain-Driven Design, come fai a sapere quando un'applicazione è complessa o solo CRUD?

What does "just CRUD" mean?

Solo CRUD significa che la tua applicazione non ha alcuna autorità propria; che sta semplicemente raccogliendo e ripetendo le informazioni che vi sono passate. Questo è tipico di un database o di un giornale , in cui l'app viene utilizzata come meccanismo per archiviare e servire i dati.

This is "just CRUD," but I've never seen a system that didn't "acting on that data" either.

Sì, normalmente c'è qualche componente che sta semplicemente memorizzando / recuperando dati. La vera domanda è: c'è qualcosa di altro , di fronte all'archivio dati, che sta prendendo decisioni autorevoli su ciò che viene memorizzato e cosa no?

Quel qualcosa sarà di solito un modello di dominio; che ha al suo interno le regole di business che determinano ciò che dovrebbe essere memorizzato.

Questo intervento da Greg Young nel 2012 potrebbe essere d'aiuto.

What is a non-complex example?

Il mio attuale esempio di go-to è determinare se una banca può addebitare o meno una commissione in ritardo. Lo fa esaminando un modello dell'attività dell'account (depositi e prelievi, modifiche nello stato del cliente preferito e così via), applicando la logica di dominio e scrivendo un messaggio che indica quali tariffe possono essere addebitate.

CRUD è l'acronimo di Crea Elimina aggiornamento di lettura.

Quindi un'applicazione che offre solo quattro metodi per creare una risorsa, leggerla, aggiornarla ed eliminarla con il suo id è un'applicazione CRUD. Non contiene alcuna logica di dominio tranne forse qualche convalida che l'entità salvata sia valida. Ma tutta la logica interessante vive al di fuori, nei chiamanti di questa applicazione e un'applicazione CRUD funge solo da archivio dati.

Spesso si dice anche che un'applicazione come quella implementa un modello di dominio anemico.

Un esempio di semplice applicazione CRUD è quando si desidera archiviare e recuperare alcuni dati ma si hanno alcune restrizioni sui dati che non possono essere soddisfatte direttamente da un database esterno o da un archivio di valori chiave. È quindi possibile creare una semplice applicazione CRUD che è fondamentalmente un involucro attorno alla soluzione di archiviazione scelta, ma aggiunge i requisiti aggiuntivi che l'archivio dati non può soddisfare da solo.

Forse un euristico per un'applicazione che non è "solo CRUD" è che gli interessi di un utente dell'applicazione sono spesso in conflitto con gli interessi dello sponsor dell'applicazione.

Quindi è possibile che sia stata creata un'applicazione "pura e semplice" per aiutare qualcuno a svolgere il proprio compito di registrazione di alcune informazioni. L'utente desidera registrare le informazioni con precisione e lo sponsor dell'applicazione desidera aiutarlo. Non c'è conflitto.

Ma con un gioco, un singolo utente potrebbe voler vincere facilmente, mentre lo sponsor dell'applicazione potrebbe volere che il gioco sia conosciuto come stimolante per attirare più giocatori e impedire facili vittorie. O in un sistema di e-commerce, ovviamente, una classe di utenti vorrebbe che tutto avesse uno sconto del 100%. Lo sponsor dell'applicazione probabilmente non lo vorrebbe.