4. Progettazione guidata dal Dominio

(Domain Driven Design) La progettazione e lo sviluppo di software sono sempre un processo creativo, in cui siete alla ricerca di soluzioni intelligenti per affrontare le sfide. Nella maggior parte dei casi software “in pronta consegna” non esiste o non risolve i problemi e una soluzione personalizzata deve essere sviluppata da zero.

La prima azione in questo processo dovrebbe essere una chiara definizione dei requisiti. Se questa è incompleta o errata si verificano incomprensioni, che portano inevitabilmente a situazioni in cui il software non soddisfa tutte le aspettative del cliente e/o non funziona a dovere. Più grande e più complesso il sistema, maggiore è il rischio che le cose vadano terribilmente male e più grande l’impatto sul tempo e il budget per portare il progetto di nuovo sotto controllo.

Spesso i requisiti si discutono e si documentano nel corso di un incontro iniziale o presentazione con il cliente. Dopo di che, le due parti tornano al loro lavoro - lo sviluppatore al suo computer per avviare la codifica e il cliente per le sue attività quotidiane.

Ad un certo punto (in genere alla prima tappa del progetto) lo sviluppatore presenta una certa fase del software per dimostrare i progressi. Succede a questo evento che le parti interessate cominciano a rendersi conto delle differenze nelle aspettative e promesse. Forse sono state chieste le domande sbagliate nel corso della riunione iniziale o ci sono semplicemente alcune incomprensioni.

Pertanto, è essenziale lavorare a stretto contatto con i clienti e comprendere appieno i loro problemi¹. Nel concetto della Progettazione guidata dal dominio, l’argomento o settore (l’area di attività del tuo cliente) si chiama domain.

Una diversa comprensione dei concetti specifici del dominio sembrano essere il motivo principale per discrepanze tra utente (client) e sviluppatore di applicazioni (fornitore di servizi).

DDD (Domain Driven Design) si basa su due presupposti importanti:

• L’obiettivo principale della progettazione del software dovrebbe essere sul dominio di base e la logica del dominio.
• disegni complessi dovrebbero essere basati su un modello di dominio.

Questo assicura che le relazioni implicite (che spesso causano problemi di comunicazione) diventano esplicite.