Quanto profondo dovremmo esplorare il dominio (sottodominio, contesto limitato) in Domain Driven Design?

0

Sono curioso del tuo approccio / euristica all'esplorazione del dominio (sottodominio, contesto limitato) durante la sessione di modellazione DDD.
Come tutti sanno, la maggior parte dei programmatori tendono ad essere perfezionisti (specialmente nei luoghi in cui non è assolutamente necessario). La nostra industria ha imparato che è estremamente importante produrre soluzioni abbastanza buone piuttosto che perfette , altrimenti il costo dello sviluppo non è bilanciato con l'effetto. Sebbene il termine abbastanza buono sia ambiguo, dipendente dal contesto, sembra che siano state stabilite linee guida che ci portano in buona direzione (nella maggior parte dei casi) - il codice più semplice che soddisfa i criteri di accettazione, utilizzando schemi di progettazione, test sviluppo guidato per citarne alcuni.
Tenendo presente questo, qual è il tuo approccio quando si tratta di esplorare il dominio? Quando sai che dovresti smettere di esplorare e passare alla prossima area / iniziare la codifica? Ovviamente ogni sessione di dominio saprai meglio il tuo dominio, esplorato più a fondo - la mia domanda riguarda la singola sessione. Si basa sull'opinione degli esperti di dominio, sulla durata della sessione di modellazione o forse su alcuni obiettivi arbitrari stabiliti dal cliente? O forse qualcosa di completamente diverso?

    
posta kadiii 04.01.2018 - 03:08
fonte

1 risposta

2

L'esplorazione di un dominio è un processo continuo e iterativo. Eric Evans nel libro DDD ha questa nozione di svolta , un'epifania che può arrivare in qualsiasi momento lungo il processo di modellazione del dominio. A volte una squadra codifica una caratteristica solo per scoprire in seguito che mancava un'astrazione geniale nascosta che rende l'intera cosa più facile da codificare e comprendere.

Il mio consiglio è di esplorare con esperti di dominio abbastanza per ottenere un modello di dominio condiviso, un glossario e una definizione sintetica dei casi d'uso da costruire, ma non penso che riuscirai a farlo bene la prima volta.

Quanto spazio da coprire esattamente in una sessione di modellazione può seguire comodamente le linee nelle metodologie che stai utilizzando: Contesti delimitati DDD, microservizi, incrementi Agile / obiettivi sprint, unità attivabili DevOps, ecc. Iniziando con un modello di immagine grande di l'intero dominio e i relativi sottodomini sono spesso utili: in genere può essere schematizzato in una riunione e aggiornato durante il percorso. Puoi anche dare un'occhiata a Event Storming per avere buoni consigli sulla portata e l'organizzazione di sessioni di progettazione.

    
risposta data 04.01.2018 - 16:59
fonte

Leggi altre domande sui tag