DDD, CQRS, ES: ne vale la pena o è solo una perdita di tempo?

Beh, sono tre cose separate e sono cose reali non solo parole d'ordine. Ma ....

• Progettazione basata su domini. Ho visto questo usato tranquillamente comunemente ora, almeno in un modo 'lite'. Penso che aiuti a definire e suddividere un sistema in parti di componenti.

• Comando Segregazione delle query. Sebbene ci siano casi in cui si desidera avere un db di sola lettura e un db di scrittura. Applicare universalmente il modello con oggetti di comando e simili non sembra dare i suoi frutti dove l'ho visto.

• Sourcing di eventi. Ho visto questo applicato a parti di un sistema, ma non mi è mai sembrato che offra molto più beneficio di una pista di controllo degli eventi. Aggiunge una quantità media di complessità e ti costringe a pensare ad alcune importanti condizioni di errore, a collidere gli eventi ecc. Quindi c'è un grosso effetto collaterale.

Come sempre con queste cose c'è più di una visione di ciò che significano e più di un modo di implementare ciascuna vista.

Quando una singola implementazione diventa popolare e si esaurisce nel tempo, si può dire che sia matura.

L'unità succede, il potenziale per erroneamente o fraintendere l'implementazione che scegli è molto basso. Ciò significa che le persone possono finire con soluzioni un po 'hacky.

Dovresti impiegare del tempo extra per capire e testare qualsiasi modello che è nuovo per te e evitare di utilizzare la tecnologia immatura nel cuore della tua app.

A volte i principi più importanti nell'ingegneria del software sono KISS e YAGNI .

Tutti i principi di ingegneria del software, linee guida, metodologie sono solo suggerimenti che esistono per orientarti lungo una rotta in cui potresti trovare una soluzione migliore rispetto a quella che altrimenti avrebbe potuto scrivere se avessi semplicemente escogitato una soluzione basata sul primo pensiero che ti è apparso in testa.

DDD, CQRS, ES e altri sono popolari per una ragione - perché qualcun altro ha provato l'approccio "Nike" di Just Do It , si sono trovati con un codebase simile a Big Ball of Mud con un vasto catalogo posteriore di Debito tecnico , ha identificato gli errori che hanno commesso nella loro progettazione o processo e ha raggruppato i consigli per aiutare gli altri a evitare lo stesso destino (e / o come scavare da quel buco una volta che sono già troppo in profondità ).

DDD, CQRS, ES, et-al non sono parole d'ordine (i veri sviluppatori li applicano a progetti reali con risultati positivi), ma non sono Silver Bullets entrambi. Per comprendere il beneficio di qualsiasi metodologia, linea guida o principio è di capire non solo come metterlo in pratica, ma anche quando seguirlo e quando non ne trarrai beneficio. Alcuni problemi si prestano in particolare a tecniche particolari, mentre altri richiedono un approccio diverso

Fornire una risposta concreta alla domanda "Ne vale la pena?" (che interpreto significhino "dovrei usarle adesso?" ) vorrebbe dare uno sguardo approfondito al progetto specifico su cui stai lavorando e prendere una decisione per quel progetto, in base ai tipi di caratteristiche che è necessario fornire (ora vs in futuro), tempo stimato, complessità, budget, scadenze, ecc.

Il tipico "costo" di DDD / CQRS / ES è più tempo speso per iterare sul tuo progetto originale e buttare via o refactoring dei bit che non funzionano - non c'è dubbio che anche se seguirai questi approcci la tua implementazione iniziale includerà molti aspetti della soluzione "Nike" / Just-do-it; la differenza fondamentale è come progredisci dopo aver unito il prototipo o la soluzione iniziale.

Come sviluppatore, è più importante garantire la tua comprensione su come applicare DDD e CQRS e come riconoscere se stai avvicinando il tuo progetto nel modo giusto. È probabile che a un certo punto li troverai utili, anche se il modo per fare il salto è usarli nella rabbia (ad esempio, provare ad applicarli a un progetto reale e iterare il tuo progetto fino a quando non ti senti a tuo agio con esso).

Il tempo trascorso a provare cose nuove è raramente sprecato anche se il processo è frustrante e si traduce in un fallimento (alcuni potrebbero addirittura dire che imparerai molto di più dal fallimento). Vale assolutamente la pena dedicare il proprio tempo alla persistenza nell'apprendimento di diversi modi di affrontare diversi problemi: la frustrazione è una parte normale di questo processo; è un segno che ci sono cose che ancora non capisci, ma questo non significa che non valga la pena di essere compreso. Ottenere una maggiore conoscenza e comprensione porterà probabilmente a diventare uno sviluppatore "migliore", anche se in realtà non applichi nessuna di queste conoscenze al tuo attuale progetto o al tuo attuale datore di lavoro.

Non farlo ... è una politica di progettazione imperfetta. Persino Greg Young ne mette in discussione l'uso, ma ancora diffonde le sue conferenze diffondendo confusione e caos nei sistemi. Ci sono alcuni casi d'uso specifici in cui può essere richiesto il controllo - ma esiste un semplice schema di comando. Un sacco di designer di sistemi hanno una mentalità da gregge sulla prossima grande cosa, principalmente per mettersi in mostra ai pari, credo. O aggiungere al proprio curriculum. La cosa più importante è costruire un sistema affidabile, facile da manutenere, facile da capire che cresca con il prodotto & la tua azienda.

Microsoft, Google, Facebook, Twitter, le principali istituzioni finanziarie - tutte società da miliardi di dollari che non hanno bisogno di ricorrere a tutte queste idee appariscenti e appariscenti. Quindi mantienilo sano e usa il buon senso quando progetti il tuo sistema. Non farti risucchiare.