DDD è una perdita di tempo? [chiuso]

Question

Googling " Per quale tipo di applicazioni è adatto DDD? " mi ha dato la seguente risposta:

  

Probabilmente il 95% di tutte le applicazioni software rientra in & # 8220; non così buono per l'utilizzo di DDD & # 8221; categorie. (vedi l'articolo )

Allora, di cosa si tratta? »?

L'applicazione su cui sto lavorando è principalmente incentrata sui dati ma contiene ancora alcune logiche aziendali e regole da applicare. Sarebbe una perdita di tempo iniziare ad applicare le tecniche DDD? Sto meglio usando un livello di accesso ai dati più convenzionale, un modello di POCO e un livello di logica aziendale? O per dirlo diversamente: qual è una valida alternativa al DDD?

Answer 1

Molti sviluppatori che pensano che DDD sia utile per il loro progetto cadono nella trappola del fatto che pensano che il loro compito sia scrivere codice. Questo non è il caso. Il lavoro di uno sviluppatore consiste nel realizzare funzionalità in modo che un problema possa essere risolto tramite il software. Ciò porta alla conclusione che la scrittura del codice non è l'inizio di ciò che uno sviluppatore sta facendo, ma la fine: il codice è il risultato dell'intero processo PRIMA che il codice sia effettivamente scritto.

DDD non riguarda la scrittura di codice, non è un processo chiavi in ??mano in 10 passaggi per ottenere un ottimo software, si tratta dell'intero processo PRIMA che il codice sia scritto, si tratta di ottenere informazioni su ciò che il problema riguarda, cosa / che partecipa a quali flussi di informazioni e che aspetto hanno questi elementi, come si relazionano tra loro ecc. ecc. In effetti, la parte più importante di DDD è creare un linguaggio che renda possibili conversazioni tra esperti di dominio e sviluppatori senza interpretazioni errate . Questo è il "linguaggio Ubiquo" di cui parla Evans. In effetti rende l'intero processo PRIMA che il codice sia scritto un processo che lascia poco a indovinare, le cose sono chiare e dirette. (quello è l'obiettivo).

Il problema con "come funziona DDD nella pratica" e "qualcuno potrebbe darmi un esempio di come scrivo codice con DDD?" e simili proviene davvero dal fatto che le persone che fanno questo tipo di domande si concentrano sulla scrittura del codice, ma non hanno idea del PERCHÉ stanno scrivendo quel codice e non altro codice. I.o.w .: se ti rendi conto che DDD riguarda la scoperta di COSA devi scrivere come funzionalità e PERCHÉ, le cose andranno a posto. COME stai scrivendo quel codice, dipende da te. Ma come detto: questo non è più il problema più grande, poiché ormai sai già cosa devi scrivere e perché.

Answer 2

sai, a volte il 5% fa più soldi di tutti gli altri 95% - ecco perché esiste DDD.

è per specifici sistemi complessi di grandi dimensioni.

Answer 3

Scusate ma se DDD fosse solo un modo di pensare come dice Frans Bouma, allora non consiglierei cose come l'ignoranza della persistenza. Questo sta respingendo gli altri come sviluppatori in qualche modo sottoclasse.

PI, per il quale DDD ha almeno una propensione, è una scelta architettonica. Non è più un modo di pensare; è già qualcosa che ti viene servito, con la maggior parte delle volte avvisi troppo vaghi per essere di qualche utilità: "non adatto a tutto".

Ma decidere di seguire la strada PI o no è una sfida in sé, e non puoi chiamare i nomi qualcuno (" un programmatore ") se si sente a disagio su questo.

Prendi un pacchetto ERP con ovunque un'interfaccia simile a MS Access: griglie con totali in esecuzione, colonne con aggiornamento automatico e scorrimento senza paginazione su 100000 record. Chiaramente un approccio DDD è adatto per pensare a come utilizzare questa app. Ma in anni non ho mai visto nessuno - né nei libri né online, nonostante le prove sostenessero spiegazioni, per non parlare di esempi di codici di vita reale, di come l'IP potesse gestire questa situazione onnipresente per chiunque volesse offrire < forte> app di livello commerciale ed esperienze utente .

Non voglio diventare religioso su questo. I sostenitori di DDD e DAL tendono ad essere eccessivamente religiosi e possono scacciare coloro che sono stati morsi una volta ma che sono / erano di mentalità aperta. Molti vogliono solo confrontarsi con esperienze di vita reale (ad esempio PENSARE) e non farsi servire solo da gatti, macchine e articoli / ordini di base (ovvero un CODICE scarso) per sostenere la predicazione.

Answer 4

Ecco una domanda molto simile: Consenti al Web Tier di accedere direttamente a DAL?

Uso DDD per tutti i miei progetti. Nelle applicazioni più piccole alcuni concetti non si applicano, ma trovo che molti aspetti siano applicabili a tutti i progetti indipendentemente dalle dimensioni.

Answer 5

DDD riguarda il software che verrà mantenuto per un po '. Per me questo significa che deve esprimere idee che cambieranno con il dominio. Sicuramente un'app semplice può essere perfetta per tempi di consegna brevi e tempi di implementazione brevi. Tuttavia, se è necessario far crescere il software, i principi DDD aiuteranno immensamente. Il DDD può essere difficile da affrontare, ma una volta che hai idea del linguaggio onnipresente e dei problemi di separazione, le cose iniziano a diventare facili.

Answer 6

Se leggi un po 'di più l'articolo, vedi questo:

  

Per il 5% delle applicazioni in cui DDD   è una buona misura, è un'ottima misura.   Per quelle situazioni, DDD ti aiuterà   rompi un dado molto duro. Ecco, DDD   potrebbe essere il proiettile d'argento per quello   lupo mannaro che solo il tuo manager   indicò la tua scrivania.

Ecco perché la confusione al riguardo.

Answer 7

• Poiché la tua app è principalmente incentrata sui dati, forse la tua architettura potrebbe essere principalmente convenzionale.

• Per gli aspetti in cui hai più logica e potenziali domini o oggetti valore, forse potresti sfruttare alcune delle idee DDD per organizzare il codice.

• In generale, l'alternativa "sana al suono" consiste nel mantenere le cose il più semplici possibile, utilizzare i concetti DDD ove utili e non complicare inutilmente le cose, come suggerisce l'articolo.

Sto iniziando un progetto simile ora, è un mix di manipolazione dei dati e più aree guidate da logica / algoritmo. Allo stesso modo, vorrei prendere le parti del DDD che andranno a beneficio del progetto, ma non cercare di forzarlo in aree dove potrebbe essere controproducente.