Che cosa utilizzo come alternativa alla progettazione basata sul dominio, se non riesco a definire un'area Competitivo-Vantaggio del mio sistema per applicarla?

5

Da tutto quello che leggo e guardo, Domain-Driven Design (DDD), è uno sforzo costoso e che richiede tempo. Infatti, tutti quelli che ho visto, tra cui Eric Evans e Greg Young, dicono non usano DDD tranne dove si ha un "Vantaggio Competitivo". Per trovare questo vantaggio, questo tipo di drop off in varie discussioni di business e T-shirt. Va bene. Capisco che è una decisione aziendale, non necessariamente DDD, anche se DDD aiuta a identificarlo.

Che cosa fa un'azienda con gli aspetti non competitivi del proprio sistema che semplicemente non possono acquistare software off-the-shelf per?

Ad esempio, un programma di inventario. Molte società hanno programmi di inventario. Molti di questi hanno le stesse caratteristiche. È il marketing che separa la maggior parte di loro e la reputazione. Per DDD, non so che tutti abbiano un Vantaggio Competitivo.

Dove si inserisce il DDD in questi scenari? Mi piacerebbe davvero usare il DDD perché mi piacciono i suoi principi, ma trovo che abbia poco senso, almeno per me, visto gli avvertimenti dei sostenitori.

Quindi, sono tornato indietro dove ho iniziato con altre metodologie di progettazione (non che siano cattive.) E, io uso la parola "metodologie" liberamente perché DDD è più sui principi, come lo sono tanti "metodi". Posso solo prendere dei principi qui (linguaggio onnipresente e così via), ma non molto altro.

Che cosa utilizzo come alternativa alla progettazione basata sul dominio, se non riesco a definire un'area Competitiva-Vantaggio del mio sistema per applicarla? Dovrei comunque usare DDD? Non sembra.

Quello che davvero non capisco è quando qualcuno non usa un analista o qualcosa di simile per capire un business. In quale altro modo gli sviluppatori saprebbero cosa scrivere? Questo non è DDD; è solo buon senso.

Non chiedere informazioni sulle tattiche qui, ma piuttosto sulla strategia (come alcuni l'ho letto.)

Esempio tratto da Vaughn Vernon, link

Parlando di Entity Framework e DDD, "Consenti a Entity Framework di mappare le entità e tornare a quello che farà la differenza in questo mondo competitivo: la tua applicazione di distinzione di mercato ."

Sembra che DDD non sia per il 90% del mondo, solo per il Magic Quadrant.

    
posta johnny 12.07.2017 - 16:56
fonte

1 risposta

11

Che ne dici di seguire la regola di requisizione di Robert (le tre R)?

Use a tool only when the benefits exceed the costs.*

Si noti che il "vantaggio competitivo" non è l'unico criterio. Ce ne sono molti altri.

Eccone un altro .. La regola del rifornimento di Robert, che recita:

You don't necessarily have to drink the entire jug of Kool-aid.

A volte ti serve solo uno strumento dell'intero toolkit. Nel caso del DDD, molti sviluppatori potrebbero trarre beneficio esclusivamente dal concetto di un "linguaggio ubiquo", non avendo né imparato né utilizzato nessuno degli altri strumenti.

E infine la legge delle migliori pratiche di Robert:

There is no such thing as a "best practice." There is only that which most effectively meets your specific requirements.

e la legge della scala di Robert:

Don't use a jackhammer when a ball peen hammer will suffice.

* Ci sono sempre dei costi.

    
risposta data 12.07.2017 - 17:09
fonte

Leggi altre domande sui tag