Plugin contro DSL esterno

Question

Plugin contro DSL esterno

#1 da (1 voti)
#2 da (0 voti)

1

Attualmente faccio parte di un team che sviluppa una soluzione destinata alle piccole imprese. Uno dei componenti è una sorta di "motore dinamico delle regole di business" (annota le virgolette) e, data la sua natura, vorremmo che fosse altamente configurabile.

La mia idea era di implementare / utilizzare un DSL esterno per scrivere le regole con una semplice utility di configurazione per crearle e modificarle. Potremmo anche mantenere un insieme di regole "comuni" e distribuirle con l'applicazione. Un DSL esterno + "editor" ci consentirà di correggere o modificare le regole secondo necessità e i nostri clienti hanno bisogno di quell'agilità nel loro processo.

I membri del mio team pensano che il miglior approccio qui sia quello di fornire le regole come plugin per l'applicazione e ridistribuire o aggiornare quei plugin, sostengono che, in questo modo, avremo un migliore controllo di qualità dato che testare i plugin essere più facile che testare uno script DSL. Ma a mio parere, mantenendo un gruppo di plugin, molti di loro in una base "per cliente" finiranno per diventare un incubo vivente.

Bottomline la mia domanda è: quale soluzione pensi che funzionerà meglio con una piccola squadra di liberi professionisti "jack of all trades" che devono sviluppare / implementare / mantenere / aggiornare circa quattro o cinque clienti?

architecture deployment

posta yorodm 11.01.2017 - 21:42

fonte

2 risposte

0

Entrambe funzioneranno. Entrambi potrebbero non funzionare

Il successo della strategia non riguarda i plugin x lingue. Il successo della strategia è nel modello informativo delle interfacce che esponi al meccanismo del linguaggio plugin / script.

Non è possibile esporre direttamente l'intero sottosistema dell'applicazione. Se lo fai, ogni modifica dell'app di base potrebbe rompere gli script. E gli script saranno in grado di accedere a cose che potrebbero danneggiare l'app.

Vorrei consigliare di scrivere una serie di interfacce di base ed esporle ad un motore di script e ad un sottosistema di plugin. L'interfaccia sarà la stessa: piccole regolazioni e configurazioni possono essere fatte come script. Ulteriori funzioni opzionali generiche possono essere distribuite come plugin.

È una buona idea lasciare che gli utenti facciano script da soli. Formale di volta in volta ispeziona i tuoi script utente, ottieni le idee, espandi il concetto e trasformale in plug-in che puoi vendere o aumentare il valore della tua app agli occhi dei tuoi clienti.

risposta data 12.01.2017 - 10:43

fonte

Leggi altre domande sui tag architecture deployment

Dove si inserisce Behat / Mink nella pipeline CI / CD Git workflow per più versioni con spese esterne

score 1 · Accepted Answer

Sono dell'opinione che non dovresti investire in una DSL con solo 4 o 5 clienti che la utilizzano potenzialmente. Dico potenzialmente perché rischi di essere considerato troppo complicato, finendo nella situazione in cui il tuo team creerà questi script DSL per i tuoi clienti. Creazione efficace di una DSL per te.

Che cosa dovresti usare? Mi piacciono i miei normali linguaggi di programmazione e strumenti sufficienti a disapprovare il dover imparare un altro DSL.