Che cos'è lo sviluppo guidato dal dominio in termini pratici? [chiuso]

Bene, prima di tutto, non penso che l'articolo di Wikipedia a cui fai riferimento sia molto buono, principalmente perché fa riferimento a un gruppo di cose che sono solo secondarie al Domain Driven Design e fa poco per illuminare chiunque sulla pratica .

Ma, come qualcuno che ha preso a cuore Domain Driven Design (che di solito è DDD, piuttosto che 3D, per quello che vale), ho sempre sentito i fondamenti del DDD sono ovvi, se si legge tanto il primo capitolo del libro di Eric Evans. Ma è un insieme di schemi e pratiche, quindi non è così facile dare un riepilogo a 3 frasi di ciò che è e quali sono i vantaggi senza entrare nei dettagli. I dettagli che risuonano con una persona potrebbero essere anche molto diversi; è probabile che 10 anni fa non avrei visto il punto affatto, me stesso.

DDD non è un proiettile d'argento. Se fatto in modo sensato, si tratta di adottare un approccio di tipo artigiano alla creazione di software e riconoscere la necessità di ridurre l'attrito cognitivo tra i team di sviluppo e le aziende per cui stanno sviluppando software. Una delle pratiche più importanti è quella di avere un livello in cui il vocabolario di dominio utilizzato dal team del software e dal team aziendale corrisponde il più strettamente possibile. Costruisci questo strato in modo iterativo quando arrivi a comprendere il problema aziendale che stai cercando di risolvere. Quando la logica aziendale è codificata in modo sensibile in questo livello, isolata da tutte le dipendenze convolute che le applicazioni aziendali hanno in genere trattando le interazioni con tali sistemi alle interfacce, il linguaggio utilizzato nel livello del dominio effettivo diventa alla fine abbastanza conciso, ovvio e leggibile. Quando rivedi il tuo modello con il business, spesso ti corregge e ti riconsci gradualmente a una comprensione più approfondita del dominio.

Considerando la forma in cui ho visto la maggior parte del software aziendale, in pratica, DDD può suonare come un proiettile d'argento, perché la maggior parte dei software aziendali ha una separazione così scarsa di preoccupazioni che è quasi impossibile da testare e il team del software vive con grande paura del cambiamento perché non ha idea di quali possano essere gli effetti collaterali di cambiamenti di codice apparentemente banali, mentre uno strato di dominio opportunamente fattorizzato sarà indipendentemente verificabile e verificabile. Ma in realtà, DDD riconosce che i sistemi raramente esistono in isolamento. DDD include schemi di coping per i sistemi legacy (strato anti-corruzione, contesti limitati, per nominare una coppia).

Se ti eserciti nella progettazione orientata agli oggetti, inclusa la disciplina dell'accoppiamento lento, e fai pratica di test unitari in modo abbastanza religioso, e impietosamente rafforzi il codice, e lavori con gli esperti di dominio mentre crei il tuo sistema, in pratica finirai con un risultato che è fondamentalmente quello di cui parlano i sostenitori del design guidato da domini.

Ci sono alcuni modelli specifici descritti nel libro di Evans che si applicano principalmente allo sviluppo di software aziendale e alcuni che sono principi universalmente universali, ma in sostanza, DDD è un approccio pragmatico allo sviluppo del software che può, nel tempo, ridurre l'accumulo di debito tecnico, e rendi i tuoi clienti più felici perché sei in grado di parlare la stessa lingua l'uno con l'altro, e offri soluzioni più efficaci grazie ai vantaggi di comprendersi meglio.

Una descrizione di alto livello potrebbe essere -

Modella le tue classi per rispecchiare le strutture dati e il comportamento del tuo dominio problematico.

Ciò ti consente di mappare le modifiche nel tuo dominio problematico direttamente ai cambiamenti nel tuo codice, quindi dovrebbe essere più facile da aggiornare man mano che il tuo dominio problematico si evolve.

ESCLUSIONE DI RESPONSABILITÀ: ho aggiunto questa risposta dopo questa domanda è stato contrassegnato come duplicato. Non sono d'accordo, ma eccoci qui. : -)

Domain-Driven Design mira a progettare software in domini di alto valore / alta complessità.

Questo si traduce in un diverso approccio per la creazione di software aziendale: c'è troppa conoscenza in gioco e la conseguenza più importante è che non si arriva alla soluzione giusta al primo colpo.

• Perché imparerai lungo la strada.
• Perché le parti interessate non diranno tutta la verità in un colpo solo.
• Perché il dominio si evolverà lungo la strada.

O la combinazione di entrambi.

In entrambi i casi hai bisogno di buone basi software per frequentemente riscrivi software. Questo è il motivo per cui il libro ha sottolineato un determinato set di pattern attorno al modello del modello di dominio: erano la combinazione più ragionevole nel 2004.

Tuttavia, l'OOP e il modello tattico non sono la cosa più importante. La padronanza tecnica è necessaria per costruire un ottimo software in modo evolutivo. Ma è solo un ingrediente della ricetta. Gli altri?

1. L'ossessione per la lingua come mezzo per scoprire sfumature nascoste.
2. Concentrati sulla visualizzazione di immagini grandi per essere in grado di offrire contenuti straordinari.
3. Coabitazione di molti modelli più semplici invece di uno più grande.
4. Enfasi su Modellazione collaborativa con gli esperti del dominio e all'interno del team di sviluppo.