Aiuto con DDD, SOA e PI

Question

Senza entrare nei dettagli cruenti, sto cercando di progettare una soluzione basata su servizi che verrà utilizzata da diverse applicazioni client.La soluzione consente agli amministratori di creare e modificare modelli di documenti utilizzati dagli utenti normali per eseguire l'immissione di dati.Il mio intento è rendere l'applicazione uno strumento di apprendimento per le migliori pratiche, tecniche, ecc.

E, allo stesso tempo, devo accogliere un ambiente schizofrenico perché i "poteri costituiti" non possono mai attenersi alle loro decisioni riguardo a tecnologie e strumenti.Ad esempio, oggi utilizzo Linq-to-SQL perché non sono pronti per passare a EF4 ma si discute anche sul passaggio a NHibernate.Quindi, devo rendere il codice il più persistente possibile per ridurre al minimo il lavoro richiesto nel caso dovessimo cambiare gli strumenti OR/M.

A questo punto, mi sono limitato a utilizzare l'approccio della classe parziale anche per estendere le classi Linq-to-SQL in modo che implementino le interfacce definite nel mio livello aziendale.Non posso accettare i POCO perché il management insiste affinché sfruttiamo tutti gli strumenti integrati, ecc.quindi devo supportare il progettista Linq-to-SQL.

Detto questo, la mia interfaccia di servizio ha un metodo StartSession che accetta un identificatore di modello nella sua firma.L'operazione si svolge in questo modo:

1. Se esiste già una sessione nel database per l'utente corrente e il modello specificato, aggiorna il record per mostrare l'attività corrente.In caso contrario, crea un nuovo oggetto di sessione.
    
2. La sessione è associata a un'istanza del modello, chiamata "modulo".Quindi, se la sessione è nuova, devo recuperare le informazioni sul modello per creare il nuovo "modulo", associarlo alla sessione e quindi salvare la sessione nel database.Se invece la sessione esisteva già, allora devo caricare anche il "form" con i dati inseriti dall'utente e memorizzati nella sessione precedente.
    
3. Infine, la sessione (con la definizione del modulo e i dati) viene restituita al chiamante.
    

Il mio primo obiettivo è creare una separazione netta tra i livelli logici della mia applicazione.Il secondo è mantenere l'ignoranza persistente (come menzionato sopra).Terzo, devo essere in grado di testare tutto, quindi tutte le dipendenze devono essere esternalizzate per una facile derisione.Sto utilizzando Unity come strumento IoC per aiutare in quest'area.

A tale scopo, ho definito la classe di servizio e i contratti dati necessari per supportare l'interfaccia del servizio.La classe di servizio avrà una dipendenza inserita dal livello aziendale che esegue effettivamente il lavoro.Ed è qui che le cose sono diventate complicate per me.

Ho provato a seguire il percorso dell'Unità di lavoro e del repository per aiutare con l'ignoranza della persistenza.Ho un ITemplateRepository e un ISessionRepository a cui posso accedere dalla mia implementazione IUnitOfWork.La classe del servizio riceve un'istanza della mia classe SessionManager (nel mio BLL).Il SessionManager riceve l'implementazione IUnitOfWork tramite l'iniezione del costruttore e delegherà tutta la persistenza all'UoW ma mi ritrovo a giocare a un gioco di shell con le varie logiche.

Tutta la logica sopra descritta dovrebbe essere nella classe SessionManager o forse nell'implementazione UoW?Voglio la minima logica possibile nelle implementazioni del repository perché la modifica della piattaforma di accesso ai dati potrebbe comportare modifiche indesiderate alla logica dell'applicazione.Poiché il mio repository funziona con un'interfaccia, come posso creare al meglio la nuova sessione (tenendo presente che una sessione valida ha un riferimento al modello, ehm, al modulo utilizzato)?Sarebbe meglio utilizzare comunque i POCO anche se devo supportare il progettista e utilizzare uno strumento come AutoMapper all'interno dell'implementazione del repository per gestire la traduzione degli oggetti?

Uffa!

So di essere bloccato nella paralisi da analisi, quindi probabilmente una piccola spinta è tutto ciò di cui ho bisogno.L'ideale sarebbe se qualcuno potesse fornire un esempio di come risolveresti il ​​problema date le regole aziendali e i vincoli architettonici che ho definito.

Answer 1

Se non usi POCO, non sarai realmente indipendente dall'archivio dati.E l'utilizzo dei POCO ti consentirà di far funzionare il tuo sistema con repository basati sulla memoria, che è ciò che probabilmente vorrai utilizzare comunque per i tuoi test unitari.

L'AutoMapper sembra carino ma non lo considererei un problema.Mappare POCO su EF4, LinqToSql, nHibernate non richiede molto tempo a meno che tu non abbia centinaia di tabelle.Quando/se i tuoi POCO iniziano a divergere dal tuo livello di persistenza, potresti scoprire che un AutoMapper non è davvero adatto alle esigenze.