La complessità della logica aziendale, chiamata in alternativa il comportamento dell'applicazione, è il fattore più importante. Il secondo fattore più importante è quanta differenza c'è tra il problema tecnico e il vocabolario aziendale utilizzato per descrivere questo problema, dal momento che il DDD riguarda la creazione di un vocabolario condiviso tra l'azienda e il team di ingegneri.
Alcuni modelli utilizzati in DDD sono generalmente utili nell'architettura di applicazioni aziendali, come il pattern di repository, il contesto limitato e l'architettura a strati. Solo perché stai utilizzando questi modelli, non significa che stai facendo un design basato sul dominio.
Se non c'è molto comportamento, vale a dire, per lo più si memorizzano dati e non si agisce su quei dati, potrebbe esserci molto meno valore nel costruire quel livello di dominio. Nella gestione dei contenuti, se tutto ciò che fai è approvato e pubblicato, forse questo può essere rappresentato dai flag nel sistema, piuttosto che dai metodi di dominio. Ma quando inizi ad aggiungere comportamenti aggiuntivi, l'appropriatezza di un livello di dominio completo diventa più evidente.
Se parliamo di gestione dei contenuti, ecco alcune regole (immaginate) che potrebbero iniziare a suggerire la necessità di DDD:
- Se la cronologia è sottoposta a embargo fino alla data xx / yy / zz, pubblica per stampare, quindi su web; se non c'è embargo, pubblica sul Web e rendi disponibile per la stampa
- Rendi questa storia disponibile dietro il paywall agli abbonati pagati immediatamente; rilascio al pubblico 2 settimane dopo.
- Dopo aver scritto una storia, inviarla a un editore per revisione, correzione di bozze e approvazione. Una volta approvato, inviarlo alla produzione. Se la produzione taglia la storia per motivi di spazio, rendi disponibile una versione estesa online.