Disclaimer: non sono sicuro al 100% di aver compreso alcune pratiche e concetti in DDD, quindi a questa domanda potrebbe essere data una risposta chiarendo le idee
Sto lavorando in un sistema legacy (scritto in PHP) in cui lo strumento database non fornisce alcuna mappatura relazionale dell'oggetto e quindi gli oggetti che escono dallo strato di accesso al database tendono ad essere, più o meno, specchi delle righe restituite dalla query.
Per i moduli più recenti, sto cercando di applicare DDD. Tuttavia, sto lottando con come costruire un modello di dominio ricco quando le mie entità non hanno relazioni. Prendiamo ad esempio il seguente requisito: users can see the messages they have previously accepted , dove un messaggio che viene accettato è, internamente, registrato da una singola nuova riga in una tabella di database.
Se usavo un ORM e le mie entità avevano relazioni, potrei scrivere qualcosa di simile a $user->getAcceptedMessages() , che restituirebbe una raccolta di entità messaggio. Tuttavia, dal momento che non ho questo, sono diviso tra due approcci:
- Popolare le relazioni come parte della costruzione dell'entità nel repository. Le query potrebbero diventare grandi, ingombranti e difficili da gestire man mano che il numero di relazioni aumenta e lo schema cambia.
- Crea servizi per azioni come questa, che dipendono dal repository e da un utente, ad esempio
UserMessageAcceptanceService. Tuttavia, sospetto che ciò potrebbe portare a un modello di dominio anemico.
O l'approccio è ragionevole in questo scenario? O una qualche forma di ORM è un requisito per applicare in modo efficace DDD?