DDD - Le domande senza risposta di un debuttante

Sì, puoi chiamare i repository all'interno delle entità. Ma dovresti farlo? Probabilmente no, spesso ti dà più problemi tecnici che ti avvantaggeranno, ma ha anche il rischio di rendere molto difficile la regolazione delle prestazioni (soprattutto perché invita un cattivo design).

Anche l'esempio di validazione non sembra giustificare la chiamata ai repository dalle tue entità. Anche il tuo esempio sembra implicare che il tuo oggetto possa esistere in uno stato non valido, questo dovrebbe essere evitato, il tuo oggetto dominio dovrebbe sempre essere in uno stato valido.

La convalida dovrebbe iniziare già al momento della creazione dell'oggetto del dominio. Se la logica di creazione è semplice, puoi mantenere questo tipo di logica nel costruttore di oggetti. Ma la logica della creazione è ancora separata dal resto della logica poiché è necessaria solo durante il tempo di creazione e non durante il resto del ciclo di vita di un oggetto. Pertanto, quando la logica di creazione diventa abbastanza complessa, come la chiamata ai repository, dovresti estrarre questa preoccupazione separata da un altro oggetto, un oggetto factory .

Hai chiarito che usi la tecnologia di frontend che crea oggetti per te. In tal caso, direi che quegli oggetti sono solo oggetti valore di applicazione che possono essere utilizzati per l'input alle vostre fabbriche di oggetti (o costruttori per quella materia). Tuttavia, la convalida dell'applicazione dei campi dovrebbe probabilmente rimanere separata dal tuo dominio.

In generale, dovresti cercare di evitare di assegnare setter di oggetti di dominio per tutte le proprietà. Invece dovresti fornire azioni di dominio sull'oggetto. Quindi, invece di avere un metodo come: setOrderStatus (Order.PROCESSED) dovresti avere un metodo processOrder (). In questo modo, ogni metodo produrrà sempre uno stato valido (o genererà un'eccezione). Nota che scrivo in generale, come per i campi banali che non hanno alcuna connessione con la logica del dominio e rappresentano solo dati, puoi comunque usare setter.

Per semplici applicazioni incentrate sui dati, questo tipo di approccio potrebbe dare troppo peso. Ma poi di nuovo, non è quello che si intende per DDD.

Ecco le mie risposte alle tue domande:

1. "ammessi"? Avrai problemi nella vita se credi troppo nel dogma. Tu e il tuo codice potete fare tutto ciò che ha senso. In questo caso, direi che non ha senso. Se ho a che fare con un'entità che è stata persistita e proviene da un repository, dovrebbe essere valida al 100%. Se non lo è, autorizzo dati non validi nel mio database. Se è di nuova costruzione, direi che programmare per contratto dovrebbe proibirmi di creare istanze non valide. Quindi non c'è mai bisogno di chiedere un database se un'entità è valida. È troppo tardi.
2. La programmazione per contratto direbbe che avresti delle regole di pre-condition nel costruttore per assicurarti di non poter mai creare un'istanza non valida. Ogni istanza creata deve essere completamente inizializzata, valida e pronta al 100% per l'utilizzo da parte dei clienti. Ho delle classi di validatori, ma di solito sono per le app Web che convalidano e associano variabili di input da moduli Web.

DDD e regole empiriche sono ottime, ma non lasciarti coinvolgere troppo da esse. Conoscere le regole; sapere quando rompere le regole.