Temo che questa domanda sembri ampia, quindi cercherò di spiegare cosa intendo con qualche dettaglio. Non potevo, tuttavia, trovare un modo per dividerlo in altre domande. Se è davvero così, accetto volentieri suggerimenti su come suddividere questa domanda in quelli più mirati.
Lavoro con la programmazione orientata agli oggetti e una delle prime cose di cui ho sentito parlare è stato il processo di OOAD dove, partendo dai requisiti, principalmente sotto forma di casi d'uso, abbiamo individuato le classi di modelli di dominio di cui avremo bisogno e le relazioni tra quelle classi.
D'altra parte, nelle ultime settimane, ho studiato su Domain-Driven Design e ci sono molte cose che sembrano aiutare molto nella progettazione orientata agli oggetti. Uno di questi è la divisione dell'applicazione con contesti limitati che risolve il problema delle confusioni sul significato di un determinato termine dal dominio. Un'altra cosa che sembra aiutare molto è l'idea di entità, oggetti valore, aggregati, repository, fabbriche, servizi ed eventi di dominio.
Ora, durante la programmazione, è chiaro come implementiamo molte di queste cose con l'orientamento e le classi degli oggetti. Il mio dubbio è: come possiamo unirci al processo di OOAD e all'uso del DDD?
Voglio dire, quando si pianifica, senza codificare nulla, come ci si unisce a OOAD e DDD? OOAD mette enfasi su alcuni lavori su carta prima della codifica, come casi d'uso, storie di utenti, diagrammi e così via. DDD non sembra parlare di questo genere di cose. In che modo DDD entra in questa fase di progettazione del progetto?
Immagino qualcosa del genere: prima comprendiamo il dominio, poi lo dividiamo in sottodomini, quindi per ogni sottodominio eseguiamo il processo di OOAD, scrivendo casi d'uso e così via e quando facciamo le lezioni teniamo presente le idee DDD. È così?