Domain Driven Design è utile / produttivo per domini non così complessi?

Nel valutare un potenziale progetto al lavoro, ho suggerito che potrebbe essere vantaggioso utilizzare un approccio di progettazione guidato dal dominio al suo modello a oggetti. Il progetto non ha un dominio eccessivamente complesso, quindi il mio collega mi ha lanciato questo:

È stato detto che il DDD è favorevole nei casi in cui esiste un modello di dominio complesso ("... Si applica ogni volta che operiamo in un dominio complesso e complesso" Eric Evans).

Ciò su cui mi sono perso è: come definisci la complessità di un dominio? Può essere definito dal numero di radici aggregate nel modello di dominio? La complessità di un dominio nell'interazione degli oggetti?

Il dominio che stiamo valutando è relativo alla pubblicazione online e alla gestione dei contenuti.

La complessità della logica aziendale, in alternativa chiamata comportamento dell'applicazione, è il fattore più importante. Il secondo fattore più importante è la distanza che esiste tra il problema tecnico e il vocabolario aziendale utilizzato per descriverlo, poiché DDD riguarda la creazione di un vocabolario condiviso tra l'azienda e il team di ingegneri.

Alcuni dei modelli utilizzati in DDD sono generalmente utili nell'architettura delle applicazioni aziendali, come il modello Repository, il Contesto limitato e l'architettura a strati. Solo perché stai usando quei modelli, non significa che stai facendo una progettazione guidata dal dominio.

Se non c'è molto comportamento, vale a dire, stai principalmente archiviando dati e non agendo su tali dati, potrebbe esserci molto meno valore nella costruzione di quel livello di dominio. Nella gestione dei contenuti, se tutto ciò che fai è approvare e pubblicare, forse può essere rappresentato dai flag nel sistema, piuttosto che dai metodi di dominio. Ma quando inizi ad aggiungere un comportamento aggiuntivo, diventa più evidente l'adeguatezza di un livello di dominio completo.

Se stiamo parlando della gestione dei contenuti, ecco alcune regole (immaginate) che potrebbero iniziare a suggerire la necessità di DDD:

• Se la storia è sottoposta a embargo fino alla data xx / yy / zz, pubblica per stampare, quindi per il web; se non vi è alcun embargo, pubblicare sul Web e renderlo disponibile per la stampa
• Rendi immediatamente disponibile questa storia dietro il paywall agli abbonati pagati; rilascio al pubblico 2 settimane dopo.
• Dopo che una storia è stata scritta, inviarla a un editore per la revisione, la correzione di bozze e l'approvazione. Quando approvato, inviarlo alla produzione. Se la produzione interrompe la storia per motivi di spazio, rendi disponibile online una versione estesa.