Oof, grande argomento. Sì, questo può essere uno schema tipico nei software di classe enterprise, ma non penso necessariamente che sia buono. Considera di evitarlo se puoi. Il problema principale qui è che esiste ad un altissimo livello di astrazione. Quando uno strumento non sa cosa l'utente vuole fare, rinuncerà inevitabilmente alla decisione e ti fornirà un quadro per costruire il tuo strumento. Ciò inizia come un buon passo per la personalizzazione delle vendite, ma in qualche modo MDA è l'ultimo creep di portata; se diventi così flessibile, in realtà non c'è nulla che il tuo software non possa fare (in teoria).

Questo è un errore talmente classico che ci sono tutti i tipi di barzellette a riguardo.

Legge di Zawinski - "tutti i programmi veramente utili sperimentano la pressione per evolvere in toolkit e piattaforme applicative "

Decima regola di Greenspun - e anche altri.

In conclusione, per me, la MDA esiste ad un livello molto alto di astrazione. I sistemi dovrebbero evitare over-abstraction . Penso che sia troppo dire categoricamente che non dovresti mai farlo, a volte potrebbe funzionare, ma è meglio che tu abbia un caso maledettamente chiuso perché è necessario prima di farlo, altrimenti direi che è un'astrazione eccessiva.

Modelli specifici di progettazione ingegneristica: in realtà si tratta di creare entità e relazioni di database in modo molto astratto e di consentire all'utente di utilizzare un'interfaccia utente per specificare e mettere in relazione tali elementi. Sul lato dell'interfaccia utente, lo stesso concetto tranne che utilizzando le entità / relazioni del database, stai usando pannelli, input, moduli, ecc.

Alternative open source - non sono sicuro su questo, ma sarei diffidente se ci sono, perché solitamente le soluzioni "super-flessibili" finiscono per essere personalizzate nel dominio del problema (CRM, o qualsiasi altra cosa). Forse alcuni dei costruttori di interfaccia e dati forniti con Eclipse?

I problemi che derivano da questi approcci sono molti.

Test della bestia

Perché è così astratto, i test diventano molto difficili. Non è possibile testare ogni combinazione, quindi progettare una suite di copertura rappresentativa è una cosa molto difficile da fare. Quella nuova funzionalità che hai sviluppato, interagisce male con la bizzarra personalizzazione del Cliente X che stava davvero lavorando contro il modo in cui lo strumento avrebbe dovuto funzionare in primo luogo?

Comprensione del tuo sistema

In secondo luogo, consente all'utente di codificare le conoscenze nel sistema che il sistema stesso non ha. Immagina un ingegnere di back-end che osserva una personalizzazione del proprio sistema e ha difficoltà a riconoscere da dove iniziare, perché conoscere la propria strada dipende dalla conoscenza al di fuori delle specifiche del sistema. Un commentatore precedente ha sottolineato che per la forza vendita, devi assumere consulenti speciali per aiutarti a implementarla. Sì, sembra giusto.

Aspettative utente inappropriate

Esiste un compromesso generale tra la potenza del sistema e la semplicità; questi sistemi sono molto potenti e tendono ad essere l'opposto del semplice. Quindi, fondamentalmente tutti gli aspetti negativi della complessità arrivano per maggiore flessibilità. Ciò crea anche negli utenti e nei product manager il senso di "possiamo fare qualsiasi cosa", il che rende molto difficile impostare e comprendere i confini del sistema appropriati.