Integrazione delle applicazioni del modello di dominio - Risorse / Guida

6

Non riesco a trovare indicazioni sull'integrazione di varie applicazioni, in genere basate su un'architettura del modello di dominio. Le applicazioni spesso espongono e consumano l'un l'altro i servizi WCF, ma questo tende a essere fatto in un modo piuttosto rischioso. Sono abbastanza sicuro che il dominio non dovrebbe accedere ad altri servizi di applicazioni, ma da dove dovrebbero essere consumati? Interfaccia utente, livello applicazione? Livello dati? Tutto quello che ho letto su SOA sembra contenere informazioni teoriche su cosa rende un servizio, ma nulla su come implementarlo realmente nel codice. E se devo tornare / interrogare su un join tra due entità in due sistemi? Molte risorse suggeriscono di denormalizzare i dati nel sistema chiamante e di aggiornare usando i messaggi, ma la messaggistica e il WCF dovrebbero essere combinati nello stesso sistema?

Ho letto Enterprise Application Integration ma mi lascia ancora molte domande. Quali sono buoni esempi di risorse / codice per l'integrazione dei sistemi di modelli di dominio?

    
posta Paul T Davies 30.09.2011 - 19:29
fonte

1 risposta

4

Non c'è alcun problema che non possa essere risolto aggiungendo uno strato di astrazione, tranne che per avere troppi livelli di astrazione.

Se hai quattro domini di quattro app disparate e stai tentando di integrare le loro funzionalità o i dati in un'unica app, utilizza i quattro domini, con un livello aggiuntivo in cima per gestire l'intervallo tra essi; ogni dominio o livello SOA parlerà con il tuo nuovo livello, il che faciliterà il passaggio dei dati attraverso i confini di ciascun dominio e fino all'applicazione, in modo che i domini possano rimanere ignari l'uno dell'altro così come sono nelle loro app originali e il livello di applicazione ha un punto di contatto, quindi non interessa il numero di domini separati che si trovano al di sotto. Esattamente come tu architetti ciò dipende dalla natura dei domini e SOA che stai integrando.

Se pensi alla tua app in un modo diverso, ad es. UI / Applicazione / Dominio / DAL / Dati e non voglio pensare che questo nuovo livello di astrazione sia il suo livello, quindi consideralo come parte del livello Applicazione. Tuttavia, di solito è meglio spiegarlo come un nuovo livello, "Interop", tra i livelli Applicazione e Dominio.

Fai attenzione all'eccezione alla regola nella prima frase. Evita di architettare il "codice lasagna", con così tanti livelli di astrazione tra livelli che anche semplici cambiamenti come l'aggiunta di un campo richiedono che tu passi la giornata a perforare tutti gli strati dell'astrazione. Dati, mappatura, campo dominio, livello servizio (client e server), DTO, livello applicazione, controller, interfaccia utente ... Si potrebbe facilmente finire per toccare una dozzina di oggetti solo per aggiungere una casella di controllo a un modulo se si è troppo separati. Evita anche il "God Object" quando implementi il tuo livello di interoperabilità; può essere allettante creare un oggetto che possa dare qualsiasi oggetto a qualsiasi altro oggetto, ma considera Fabbriche e Convertitori con ambiti più piccoli che sono gestiti da oggetti supervisore (ancora, nessun problema che non puoi risolvere con un altro livello di astrazione ... ).

    
risposta data 30.09.2011 - 22:15
fonte

Leggi altre domande sui tag