Analisi e progettazione orientata agli oggetti e DDD insieme

0

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ì?

    
posta user1620696 20.02.2015 - 01:31
fonte

2 risposte

6

Eric Evans ha affermato che il DDD è solo un buon design orientato agli oggetti. Lo ha appena scritto e gli ha dato un nome accattivante. I due non sono in disaccordo, sono, in effetti, uno e lo stesso.

    
risposta data 20.02.2015 - 01:39
fonte
2

Ho riflettuto sull'applicazione di UML e Patterns di Craig Larman e Domain-Driven Design di Eric Evans e sebbene entrambi sembrino affrontare lo stesso problema da una prospettiva a volo d'uccello, hanno filosofie diverse.

OOA / D è una sorta di "cascata-y" perché si ricava un modello dai requisiti usando "oggetti del mondo reale" e lo si traduce in un diagramma di classe che implementa successivamente.

Evans d'altra parte dice che dovresti sviluppare un modello di dominio che ti aiuti a costruire un linguaggio comune - l'Ubiquitous Language - che tutti nel team parlano e capiscono. Non c'è analisi e progettazione nel senso OOA / D.

A partire dal modello di dominio e dall'Ubiquitous Language gli esperti di dominio possono scrivere casi d'uso più precisi e gli sviluppatori possono provare a implementare il modello di dominio. Se l'implementazione non assomiglia al modello di dominio non significa che sia sbagliata, ma significa che non funziona nel tuo caso, quindi devi perfezionarlo. Se gli esperti di dominio non riescono a ripetere i casi d'uso sensibili, ciò non significa che sia sbagliato. È solo che manca qualcosa e il modello di dominio dovrebbe essere rivisto.

Secondo Evans questo ciclo di feedback è cruciale quando si fa DDD.

Questo è probabilmente un approccio più da manuale. Fuori 'in the wild' i due potrebbero non essere così diversi.

Per capire come integrare i due: la costruzione di un modello di dominio e l'Ubiquitous Language dovrebbero far parte di un primo seminario. Se ci sono già alcuni casi d'uso, puoi convalidarli parlando di loro. Se non ci sono, beh, sarà molto più facile scriverli ora.

    
risposta data 02.06.2015 - 23:39
fonte

Leggi altre domande sui tag