Ho sentito parlare di Domain Driven Development da uno sviluppatore nell'area. Lo ha parlato come se fosse solo il proiettile d'argento a cambiare i requisiti.
Ho letto il wiki . Ancora non troppo chiaro. Che cosa è "3D" in termini pratici? È davvero così sorprendente che ora il diagramma di classe UML sia semplicemente obsoleto?
Risposte:
Bene, prima di tutto, non penso che l'articolo di Wikipedia a cui ti riferisci sia molto buono, principalmente perché fa riferimento a un mucchio di cose che sono solo accessorie al Domain Driven Design e fa ben poco per illuminare chiunque sulla pratica.
Ma, come qualcuno che ha preso a cuore Domain Driven Design (che di solito va da DDD, piuttosto che 3D, per quello che vale), ho sempre sentito i fondamenti di DDD ovvi, se leggi tanto quanto il primo capitolo di Eric Il libro di Evans. Ma è un insieme di schemi e pratiche, quindi non è così facile fornire un riassunto in 3 frasi di cosa sia e quali siano i vantaggi senza entrare nei dettagli. Quali dettagli risuonano con una sola persona potrebbero anche essere molto diversi; è probabile che 10 anni fa non avrei visto il punto, me stesso.
DDD non è un proiettile d'argento. Se fatto in modo ragionevole, si tratta di adottare un approccio artigianale nella creazione di software e di riconoscere la necessità di ridurre l'attrito cognitivo tra i team di sviluppo e le aziende per cui stanno costruendo software. Una delle pratiche più importanti è quella di disporre di un livello in cui il vocabolario di dominio utilizzato dal team del software e dal team aziendale corrisponda il più fedelmente possibile. Costruisci questo livello in modo iterativo mentre comprendi il problema aziendale che stai cercando di risolvere. Quando la logica aziendale viene codificata in modo sensato in questo livello, isolato da tutte le dipendenze contorte che le applicazioni aziendali hanno in genere fattorizzando le interazioni con tali sistemi fino alle interfacce, il linguaggio utilizzato nel livello di dominio effettivo alla fine diventa abbastanza conciso, ovvio e leggibile.
Considerando la forma in cui ho visto la maggior parte dei software aziendali, in pratica, DDD potrebbe sembrare un proiettile d'argento, perché la maggior parte dei software aziendali ha una separazione così scarsa delle preoccupazioni che è quasi non verificabile, e il team del software vive nella paura del cambiamento perché non hanno idea di quali potrebbero essere gli effetti collaterali di apparentemente anche banali modifiche al codice, mentre un livello di dominio adeguatamente ponderato sarà testato e verificabile in modo indipendente. Ma in realtà, DDD riconosce che i sistemi raramente esistono in modo isolato. DDD include modelli di coping per sistemi legacy (livello anticorruzione, contesti limitati, per citarne un paio).
Se pratichi una progettazione orientata agli oggetti, inclusa la disciplina dell'accoppiamento libero, e pratichi i test unitari in modo abbastanza religioso, e rifatti il codice senza pietà e lavori con esperti di dominio mentre costruisci il tuo sistema, essenzialmente finirai con un risultato che è sostanzialmente ciò di cui parlano i sostenitori della progettazione guidata dal dominio.
Ci sono alcuni schemi specifici descritti nel libro di Evans che si applicano principalmente allo sviluppo di software aziendale, e alcuni che sono principi abbastanza universali, ma essenzialmente DDD è un approccio pragmatico allo sviluppo del software che, nel tempo, può ridurre l'accumulo di debito tecnico, e rendere i tuoi clienti più felici perché sei in grado di parlare la stessa lingua tra loro e fornire soluzioni di lavoro migliori a causa dei vantaggi di conoscersi meglio.
Una descrizione di alto livello potrebbe essere -
Modella le tue classi per rispecchiare le strutture dei dati e il comportamento del tuo dominio problematico.
Ciò ti consente di mappare le modifiche nel tuo dominio problematico direttamente alle modifiche nel tuo codice, quindi dovrebbe essere più facile aggiornarlo man mano che il tuo dominio problematico si evolve.
DISCLAIMER: ho aggiunto questa risposta dopo che questa domanda è stata contrassegnata come duplicata. Non sono d'accordo, ma eccoci qui. :-)
Domain-Driven Design mira a progettare software in domini di alto valore / alta complessità.
Questo si trasforma in un approccio diverso per la creazione di software aziendale: c'è troppo apprendimento in gioco e la conseguenza più importante è che non riuscirai a trovare la soluzione giusta al primo colpo.
O la combinazione di entrambi.
In entrambi i modi avrai bisogno di basi software valide per riscrivere frequentemente il software. Questo è il motivo per cui il libro ha sottolineato un determinato insieme di modelli attorno al modello del modello di dominio: erano la combinazione più ragionevole nel 2004.
Tuttavia, OOP e il modello tattico non sono la cosa più importante. La padronanza tecnica è necessaria per costruire grandi software in modo evolutivo. Ma è solo un ingrediente della ricetta. Gli altri?