Ho avuto alcune iterazioni di DDD con alcuni progetti diversi, tuttavia continuo a lottare con la definizione appropriata dei contesti limitati. Mi trovo continuamente a voler creare aggregati molto granulari. Questo è diventato ancora più vero una volta che ho introdotto l'event sourcing nel mix.
Ecco un esempio concreto. Diciamo che sto progettando un software come Photoshop. Fin dall'inizio, posso vedere che avrò un oggetto dominio per il Design. Ora tutti dicono che non progettano domini che non possono reggersi da soli. Questo è dove lotto. Se volevo aggiungere una funzione alla mia applicazione simile a Photoshop per supportare più livelli nel design, il concetto di un livello non ha senso al di fuori del Design. Non "regge da solo". Quindi mi sembra che dovrebbe essere un oggetto di valore del design. La stessa cosa vale per gli elementi grafici reali che possono essere inclusi in un livello. Ma non ha molto senso, perché Value Objects dovrebbe essere immutabile.
Sto cominciando a chiedermi se sto interpretando la frase "stand alone" in modo errato. Ciò significa in realtà che l'oggetto dominio può essere manipolato al di fuori del contesto degli altri domini. Quello che preferirei fare è fare in modo che Design, Layer ed Element abbiano tutti i propri Oggetti Dominio, che mantengono riferimenti l'uno con l'altro da Id. Dal momento che sto andando verso il basso nel percorso ES, pubblicheremo quindi gli eventi del dominio interessato e un ascoltatore aggiornerebbe le relazioni tra questi domini.
C'è un percorso diverso in cui dovrei essere o una diversa interpretazione del DDD?