Applicazione di DDD a un'app semplice con un tocco di configurazione

0

Sto utilizzando il leggero PHP Fat-Free Framework come base per formare una semplice app basata su MVC con filosofia DDD per il modello strato. Sono consapevole del fatto che DDD è la soluzione più adatta o aziendale e che applicare DDD a semplici app per lo più basate sui dati è un po 'eccessivo, ma ci sono alcuni concetti in DDD che trovo allettanti (come il pattern Repository, la logica di business in Entità, ecc.) Che mi piacerebbe applicare alla mia app.

Fat-Free Faramework ha una classe Base che rappresenta l'applicazione (un Singleton) e l'istanza di Base contiene molti strumenti utili e un registro di variabili globali (l'alveare) che viene usato, tra le altre cose, per i dati di configurazione.

Mentre scrivo la mia app, mi trovo a utilizzare molti strumenti di classe Base all'interno delle classi nel livello Model e sono un po 'confuso da come fare riferimento all'istanza Base in quelle classi. Chiaro semplicemente Base: instance () all'interno delle classi del modello o lo inietto tramite il costruttore come dipendenza? L'iniezione delle dipendenze sembra il modo corretto per farlo, ma dal momento che la maggior parte dell'app dipende da questo, l'intero riferimento che passa attraverso il costruttore non sembra necessario. Inoltre, come passare per un esempio di dati di configurazione del database alle classi di persistenza dei dati che sono archiviate nell'alveare? Dovrebbe essere passato dai Controllori durante l'istanziazione dei Repository o richiamato direttamente dal Repository (o dal Data Mapper)? Sto cercando un modo che non mi ritorni contro, quindi sto cercando qualche intuizione o consiglio su questo.

La seconda parte del mio problema è che sto cercando di scrivere la mia app in modo che ogni Entità e logica aziendale ad essa correlata sia configurabile dalla classe Entity. Questa è un'idea ispirata da Sails.js Sto ancora testando, ma per un esempio, ho un metodo getProperties () che restituisce una matrice di dati di configurazione definiti dall'utente per ogni proprietà Entity, ad esempio:

'title' => array(
    'type' => 'text',
    'minLength' => 30,
    ...
)

o per associazioni:

'children' => array(
    'entity' => 'ChildClass',
    'relation' => 'oneToMany'
)

Potrebbe sembrare un po 'controverso, ma ho testato la funzionalità di business logic e finora funziona correttamente per me, e il codice client comunica con le entità tramite i normali metodi get / set / other. L'idea alla base di tale configurazione è quella di essere in grado di generare automaticamente l'interfaccia di scaffolding / amministrazione per ogni Entità e configurare Data Mapper e Repository basati sul metodo getProperties () dell'entità correlata.

Ciò che mi infastidisce ora è che se voglio avere un luogo in cui esistono questi dati di configurazione, dovrei inserire alcune logiche di dominio non business nell'entità, come un eccezionale nome della tabella del database, se un campo richiede o meno un editor di testo RTF, se una casella di controllo è selezionata per impostazione predefinita, un determinato campo utilizzato come identità di stampa di un'entità nell'interfaccia web di amministrazione, ecc.

Mi rendo conto che il problema che ho è un compromesso tra un modello pulito e l'idea di configurazione a posto singolo e che probabilmente dovrò inquinare le Entità memorizzando tali dati di dominio non di business nelle Entità, ma io pensavo che forse qualcuno qui potrebbe avere un'idea di come affrontarlo in un modo diverso o migliore?

Grazie per la lettura.

    
posta Martin Vrkljan 19.05.2014 - 10:24
fonte

1 risposta

2

Sento che stai mescolando le preoccupazioni qui. Le tue entità dovrebbero essere esclusivamente sulla logica di business; Posso quasi garantirvi che la lunghezza minima di un titolo non è la logica aziendale (salvo alcuni domini aziendali molto speciali). Informazioni sulla convalida (iniziale) o sul modo in cui il rendering di un campo appartiene ai modelli di visualizzazione dell'interfaccia utente.
Se non sei sicuro, trova un processo aziendale che si comporti diversamente quando non viene soddisfatta la lunghezza minima di un titolo.

Trovo strano che sia necessario fare riferimento a variabili di configurazione globali all'interno delle entità correlate alla logica aziendale. Se è così, allora mancano concetti nel tuo modello di business, o stai mescolando le preoccupazioni infrastrutturali con il tuo modello.

Per quanto riguarda la domanda per l'iniezione della dipendenza: se ne hai, ad es. repository che necessitano di stringhe di connessione, quindi utilizzare il constructor injection e utilizzare il contenitore IoC per collegare tutto insieme. Non assumere dipendenze statiche su tutto il tuo codice; ostacolerà seriamente qualsiasi collaudo di unità che vorresti intraprendere, accoppierà una gran parte della tua base di codice a un dettaglio di implementazione e farà piangere il piccolo Jezus.

Per inciso: l'hai toccato, ma voglio ribadirlo ancora: quello che stai descrivendo non è DDD.
DDD si occupa della discrepanza tra il modo in cui viene eseguito il codice e il modo in cui i processi di business effettivi vengono eseguiti il più piccoli possibile. Si tratta di modellare il dominio di un'azienda all'interno del codice, utilizzando la stessa lingua utilizzata dall'azienda. E si tratta di riconoscere che avrai bisogno di modelli diversi per le diverse parti del business, quindi partizionare la tua applicazione.
I modelli che descrivi sono un mezzo per un fine; applicarli senza gli aspetti fondamentali di DDD è quello che viene comunemente indicato come "DDD lite". Non prendere questo come me dicendo che è necessario perseguire DDD, ma è importante sapere la differenza.

    
risposta data 19.05.2014 - 12:41
fonte

Leggi altre domande sui tag